Os riscos de segurança em software para a saúde

No passado, os softwares relacionados à saúde eram aplicados principalmente em funções administrativas relativamente não críticas, nas quais o potencial de causar danos ao paciente era baixo em contraste com o risco de interrupção da organização.

No passado, os softwares relacionados à saúde eram aplicados principalmente em funções administrativas relativamente não críticas, nas quais o potencial de causar danos ao paciente era baixo em contraste com o risco de interrupção da organização. Geralmente, os sistemas clínicos não eram sofisticados e frequentemente apresentavam um grande conteúdo administrativo (e não clínico) e pouco apoio à decisão. Mesmo os sistemas de apoio à decisão clínica tendiam a ser leves, relativamente simples e compreensíveis em sua lógica, e usados como um complemento básico para as decisões, em vez de constituir-se em uma grande influência na qual se confia rotineiramente.

Isso mudou e continuará a mudar substancialmente. A natureza destas mudanças aumentará o potencial de riscos para os pacientes. Têm ocorrido alguns incidentes negativos de grande destaque relacionados com software clínico, por exemplo, na área de triagem e recepção de pacientes e/ou recall, nos quais os problemas de funcionamento do software resultaram em falha ao chamar pacientes em risco. Tais incidentes não só causaram angústia para muitos pacientes envolvidos, mas também podem ter levado a mortes prematuras.

A confiança do público foi gravemente prejudicada. O escopo de triagem de doenças está aumentando significativamente, e é nesses aplicativos, que envolvem um grande número de indivíduos, que haverá grande dependência, tanto administrativa como clínica, de softwares para detectar elementos normais e anormais e para chamar ou processar aqueles considerados como estando em risco. Tal software precisa ser seguro para o propósito a que se destina.

Existe uma preocupação crescente em todo o mundo com o número substancial de incidentes clínicos evitáveis que causam um efeito adverso nos pacientes e dos quais uma proporção significativa resulta em morte evitável ou incapacidade grave. Vários destes incidentes evitáveis envolvem diagnósticos ou outras decisões inconsistentes ou erradas. Muitas vezes um fator contribuinte é a informação em falta ou incompleta, ou simplesmente ignorância, por exemplo, a respeito de opções clínicas em circunstâncias difíceis ou reações cruzadas de tratamentos.

Cada dia está mais confirmado que os sistemas de informação, como apoio à decisão, protocolos, diretrizes e linhas de cuidado, poderiam reduzir acentuadamente estes efeitos adversos. Somente este motivo (independentemente de outros que existem) está conduzindo ao aumento na utilização de sistemas de apoio à decisão e de gerenciamento de doenças, que, inevitavelmente, se tornarão mais sofisticados e complexos.

Também se pode prever que, devido às pressões de tempo e dos aspectos médico-legais, os clínicos dependerão cada vez mais destes sistemas com menos questionamentos sobre seu resultado. De fato, à medida que estes sistemas se tornam integrados aos cuidados médicos, qualquer falha em usar instalações, padrão de apoio pode ser criticada por motivos legais. Pode-se prever um aumento no suporte à decisão não somente no tratamento clínico, mas também em outras áreas importantes para a segurança do paciente, como a tomada de decisão de encaminhamento, em que a falha em realizar um encaminhamento correto ou realizar um encaminhamento a tempo pode causar graves consequências.

Pressões econômicas também estão levando a mais sistemas de suporte à decisão. A área de prescrição genérica e/ou econômica é a mais óbvia, sendo outra a economia no número e custo de ensaios de investigação clínica. Sistemas como os de suporte à decisão têm um considerável potencial para reduzir erros clínicos e melhorar a prática clínica. Por exemplo, um grande corpo de evidências publicadas oferece testemunho da redução de erros e incidentes adversos, resultantes da implantação da prescrição eletrônica.

No entanto, todos estes sistemas também carregam o potencial de causar dano. Os danos podem, obviamente, resultar do uso sem questionamentos e/ou não profissional, embora os fabricantes possam mitigar estas circunstâncias por meio de, por exemplo, instruções de uso, treinamento e técnicas de apresentação na tela, orientação ou instrução. O potencial de dano pode estar igualmente no projeto de sistema, em áreas como: fraca base de evidências para o projeto; falha na lógica do projeto em representar adequadamente as intenções de projeto; falha na lógica para representar boa prática ou evidências na fase de projeto; apresentação insatisfatória ou confusa da informação ou funcionalidades de busca precárias; falha em atualizar em sincronia com o conhecimento mais atual.

Algumas destas deficiências de sistemas são insidiosas e podem ser invisíveis ao usuário. Em muitos sistemas nacionais de saúde, é evidente um aumento substancial nos gastos com gestão da informação e tecnologia. Os cronogramas associados são apertados e as metas são ambiciosas. Pode-se esperar que este aumento no gasto atraia novos fabricantes e alguns destes podem ser inexperientes nos processos de assistência à saúde.

Esta circunstância pode levar a um ambiente de aumento nos riscos ao bem-estar do paciente. Parte da explosão na tecnologia de informação e comunicação previsível ocorrerá na telemedicina. Muitos dos produtos de software para saúde que suportam estes aplicativos serão inovadores e não experimentados, e a distância entre clínicos e pacientes aumentará a possibilidade de erros assim como os tornará menos evidentes.

Da mesma forma, o aumento no uso de dispositivos móveis inovadores e o seu uso em novos campos provavelmente estão associados a riscos. Considerando que se está a muitos anos de distância de hospitais sem papel e sem filme, as práticas de clínica geral estão indo nesta direção. A incapacidade de recorrer ao papel e filmes traz maior dependência de computadores e bancos de dados. Corrupção e perda de dados podem não apenas trazer caos administrativo, mas também podem afetar o atendimento ao paciente de forma significativa.

Em suma, o potencial de causar danos aos pacientes decorrentes do uso de tecnologias de informação e comunicação (TIC) em aplicações para a saúde aumentará, à medida que o uso de TIC em aplicações de saúde cresça, a sofisticação dos aplicativos aumente e a confiança nas TIC cresça. Há evidência de crescente preocupação entre os profissionais e o público com incidentes de mau funcionamento de software que levam a consequências adversas à saúde, aumentando a conscientização do público.

Consequentemente, várias organizações de saúde estão cada vez mais concentradas nos padrões de garantia de controles, incluindo aqueles sobre governança e gerenciamento de risco. Uma característica importante destes controles consiste no gerenciamento de risco no contexto de danos aos pacientes e deficiências na qualidade assistencial. Estes controles geralmente envolvem a compra e a aplicação de produtos de software para a saúde.

Falhas e deficiências em produtos de software para a saúde podem, é claro, apresentar impactos adversos, além de causar danos aos pacientes. Elas podem, por exemplo, criar inconveniências administrativas ou mesmo gerar caos administrativo, com uma variedade de possíveis impactos na organização, incluindo perdas financeiras. O dano causado a um paciente também pode resultar em impacto na organização, como perdas financeiras resultantes de litígios.

Considerando que estes impactos organizacionais adversos serão significativos para uma organização, eles não são objeto desta especificação técnica, a menos que resultem em danos a um paciente. Por exemplo, a falha do sistema central de administração de pacientes de um hospital certamente causará transtornos administrativos substanciais, mas este impacto adverso não está, por si mesmo, no escopo desta especificação técnica, a menos que tenha o potencial de causar danos a um paciente (o que é possível).

O tema desta especificação técnica é o dano potencial ao paciente. Em muitos países assegura-se a segurança de medicamentos e de dispositivos médicos por meio de uma diversidade de medidas legais e administrativas; por exemplo, na União Europeia se está sujeito a várias diretivas da UE. Estas medidas são, muitas vezes, apoiadas por uma série de normas relacionadas com a segurança, provenientes de várias fontes, nacionais e internacionais, incluindo a International Organization for Standardization (ISO), o European Committee for Standardization (CEN) e a International Electrotechnical Commission (IEC).

Estes controles legislativos frequentemente abrangem o software necessário para a aplicação ou funcionamento correto de um dispositivo médico. No entanto, outros softwares aplicados à saúde geralmente não estão cobertos desta maneira. Esta especificação técnica se refere ao software aplicado à saúde, excluindo o que é necessário para a aplicação ou funcionamento corretos de um dispositivo médico. Um precursor necessário para estabelecer e implementar controles apropriados de projeto e produção, para minimizar os riscos aos pacientes decorrentes do mau funcionamento do produto ou do seu desempenho inadequado, é um entendimento claro dos riscos que um produto pode apresentar aos pacientes se puder ocorrer mau funcionamento ou um evento não intencional, e a possibilidade deste mau funcionamento ou evento causar danos ao paciente.

Além disso, se os fabricantes de produtos de software para a saúde forem orientados no projeto e controle de produção (e os correspondentes padrões produzidos), então será preciso reconhecer que os controles necessários para produtos com baixo risco não serão os mesmos que para aqueles apresentando riscos elevados. Os controles precisam corresponder ao nível de risco que um produto pode representar para um paciente.

Com este fim, muitos padrões, legislações e especificações que lidam com o controle de riscos, tanto em projeto como em produção, agrupam produtos em um número limitado de classes ou tipos, de acordo com o risco que podem representar. Esta especificação técnica apresenta um processo para este tipo de agrupamento de produtos de software para a saúde. Ela propõe cinco classes de risco e facilitará uma ampla triagem de tipos genéricos de produtos e de produtos individuais, de forma a permitir diferentes níveis, ou rigor, na aplicação de controles de projeto e produção compatíveis com o risco.

Assim, a classificação proposta pode ser a precursora para padrões de projeto e de controles de produção, em que os últimos podem requerer uma análise de risco muito mais detalhada, aprofundada e rigorosa para um produto específico daquele requerido para o processo de classificação mais amplo descrito nesta especificação técnica. São oferecidos exemplos da aplicação do processo de atribuição de uma classe de risco para vários tipos diferentes de produtos de software de saúde.

O termo produtos de software para a saúde refere-se a qualquer produto de software para a saúde, esteja ou não colocado no mercado, e esteja à venda ou seja distribuído gratuitamente. Esta especificação técnica, portanto, abrange produtos comerciais, bem como, por exemplo, software de código aberto e softwares criados para, e usados em, uma única organização de saúde, como um hospital. Existe uma ampla gama de produtos de software para a saúde, que vão desde simples bancos de dados de pesquisa até sistemas de chamadas e rechamadas, suporte a decisões clínicas, sistemas de registros eletrônicos de saúde, sistemas de despacho de ambulância, sistemas de laboratório clínico hospitalar e sistemas de clínica geral. O Anexo B fornece quatro exemplos da aplicação desta especificação técnica a diferentes produtos de software para a saúde. Entretanto, qualquer software que seja necessário para o uso adequado ou para o funcionamento de um dispositivo médico está fora do escopo desta especificação técnica.

A ABNT ISO/TS25238 de 09/2019 – Informática em saúde – Classificação dos riscos de segurança em software para a saúde preocupa-se com a segurança dos pacientes e fornece orientação sobre a análise e a categorização dos perigos e riscos que os produtos de software para a saúde apresentam para os pacientes, a fim de permitir a classificação de qualquer produto em uma das cinco classes de risco. É aplicável aos perigos e riscos que podem causar danos a um paciente. Outros riscos, como riscos financeiros ou organizacionais, estão fora do escopo desta especificação técnica, a menos que tenham potencial de prejudicar um paciente.

É aplicável a qualquer produto de software para a saúde, quer seja ou não colocado no mercado, e esteja à venda ou seja gratuito. São oferecidos exemplos da aplicação do esquema de classificação. Não se aplica a qualquer software que seja necessário para a correta aplicação ou para o funcionamento de um dispositivo médico. Destina-se a classificar o software para a saúde em classes de risco amplas, para auxiliar em decisões como, por exemplo, quais controles convém que sejam aplicados para garantir a segurança. Não se destina à aplicação da análise de risco e gerenciamento de risco ao projeto de produtos de software para a saúde e à mitigação de quaisquer riscos identificados a níveis aceitáveis (ver Anexo A).

Acesse algumas questões relacionadas a essa norma GRATUITAMENTE no Target Genius Respostas Diretas:

Quais os perigos de uma atribuição de categorias de consequência?

Qual é a atribuição de possibilidade a consequências?

Qual é o conceito das classes de risco?

Como executar a análise de consequências?

Qual é o relacionamento de classes de risco ao projeto e controle de produção de produtos?

Convém que os fabricantes de produtos de software para a saúde possuam um claro entendimento dos perigos que o seu produto pode representar para um paciente, se ele funcionar de maneira errada ou causar um evento inesperado, e do grau de possibilidade de que o perigo se concretize se ele ocorrer em circunstâncias razoáveis de uso. Este conhecimento é necessário para a extensão e natureza das medidas de controle necessárias e o rigor com que elas precisam ser aplicadas, assim como para reduzir os riscos aos pacientes a níveis aceitáveis, por exemplo, por meio de medidas como características inerentes de projeto, instruções de uso e treinamento de indução.

O que é tolerável dependerá das circunstâncias e das atuais visões da sociedade e reguladores. O precursor essencial para este processo é realizar uma análise de perigos e riscos. Existem diversas abordagens para realizar as análises de perigos e riscos, sendo que todas compartilham um conjunto de conceitos básicos. Os padrões, diretrizes e publicações existentes tendem a focar em setores específicos de atividade (por exemplo, sistemas de segurança eletrônica, aeronáutica) ou áreas de conhecimento (por exemplo, riscos financeiros, riscos à propriedade, riscos à segurança de dados pessoais).

Desta forma, necessitam de interpretações no contexto de produtos de software para saúde. Esta especificação técnica se inspira em uma diversidade de fontes para se manter alinhada com princípios geralmente aceitos. A Bibliografia fornece uma lista de fontes de informação úteis no contexto. Ao considerar a abordagem a ser adotada para produtos de software para a saúde, tem-se que atentar para como os dispositivos médicos são classificados e controlados em termos de segurança. O Anexo A trata desta matéria.

A seguir são apresentados alguns dos conceitos básicos, na forma como são utilizados nesta especificação técnica. Esta seção não pretende abranger todos os aspectos da análise de perigo/risco. O risco para a segurança de um paciente ou pacientes a partir de um produto de software para a saúde dependerá das possíveis consequências que podem resultar, se o produto funcionar de forma errada ou resultar em um evento ou eventos adversos, e da possibilidade de que estas consequências possam acontecer de fato.

Desta forma, o risco possui dois aspectos: consequência e probabilidade. O ISO Guide 51 define risco como a combinação da probabilidade de um evento e sua consequência, enquanto esta especificação técnica define risco como a combinação da possibilidade de ocorrência de dano e a gravidade deste dano (2.7). A probabilidade que um perigo se concretize pode, em alguns domínios, ser quantitativamente representada como uma probabilidade que pode estar baseada em análises de falhas históricas ou experimentais e estatísticas de incidentes.

É muito improvável que esta situação ocorra com a segurança de produtos de informática em saúde, uma vez que estas estatísticas e evidências não estão disponíveis e, desta forma, são necessários julgamentos qualitativos. Ainda que a probabilidade possa ser representada qualitativamente, o termo possibilidade representa melhor este significado e é usado nesta especificação técnica.

O ISO Guide 73:2002 define risco como a combinação da probabilidade de um evento e sua consequência”. Esta definição possui os mesmos problemas que o uso do termo probabilidade ao invés de possibilidade. Entretanto, esta especificação técnica está focada somente em eventos que são propensos a causar dano a pacientes e a gravidade deste dano, mais do que outros eventos.

Desta forma, não é usado o termo evento. A consequência, ou seja, o dano ao paciente, pode ocorrer de diferentes formas, variando da morte a inconvenientes menores, por exemplo. Consequências podem ser categorizadas. Estas categorias precisam ser interpretadas de acordo com a sua esfera de aplicação, neste caso a aplicação de TIC à saúde.

Esta Especificação Técnica propõe cinco categorias de consequências, cada uma com uma descrição de seu escopo (ver 5.2). A possibilidade de um perigo se concretizar em circunstâncias razoavelmente previsíveis pode, em alguns domínios, ser quantitativamente representada como uma probabilidade que pode estar baseada em análises históricas ou experimentais de falhas e na análise de incidentes.

É muito improvável que este seja o caso para a segurança de produtos de software para a saúde para os quais não estão disponíveis estatísticas e evidências e, deste modo, são necessários julgamentos qualitativos. Esta especificação técnica propõe cinco categorias de possibilidade, cada uma com uma descrição de seu escopo (ver 5.3). Como notado anteriormente, o risco para a segurança de um paciente ou pacientes de um produto de software para a saúde depende das possíveis consequências que podem ocorrer se o produto tiver mau funcionamento ou resultar em um ou mais eventos adversos, e da possibilidade de que estas consequências possam ocorrer de fato. O nível de riscos pode ser representado em uma matriz de riscos na qual a possibilidade e a consequência são suas duas dimensões (ver tabela abaixo).

Cada célula da matriz representa um nível de risco. Desta forma, na matriz de risco da tabela, as 25 células representam 25 resultantes de risco, que diminuem de gravidade ao mover-se diagonalmente do quadrante superior esquerdo para o inferior direito. Estas resultantes de risco podem ser agrupadas em classes como as seguintes: a classe de risco mais alta pode ser um grupo de células na parte superior esquerda, como 1, 2 e 3; a classe de risco mais baixa pode ser um grupo de células na parte inferior direita, como 4, 5 e 6.

As células na matriz de riscos podem, desta forma, ser preenchidas com classes de risco. Ao agrupar conjuntos de células em uma classe, considerações precisam ser tomadas sobre as circunstâncias no setor de aplicação e os significados atribuídos a cada categoria de consequência e possibilidade. O objetivo é reduzir a complexidade por meio da identificação de células que representem de forma ampla um grau similar de risco ao paciente e agrupá-las em uma classe com este perfil. Assim, uma consequência menor, com uma alta possibilidade, geralmente pode se equiparar a uma consequência pior, mas com menor possibilidade. Esta especificação técnica propõe cinco classes de risco.

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão /  Alterar )

Google photo

Está a comentar usando a sua conta Google Terminar Sessão /  Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão /  Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão /  Alterar )

Connecting to %s

%d bloggers like this: