Quando é que um software de saúde é considerado dispositivo médico

Para uma equipa que desenvolve software de saúde, a resposta a esta pergunta muda o prazo e o custo do projeto. O mesmo código pode ter um peso de conformidade muito diferente consoante a forma como o produto é definido.

Imagine duas aplicações. Ambas recolhem os sintomas introduzidos pelo utilizador, executam um algoritmo e devolvem uma lista. O código é quase idêntico. Uma está sujeita à regulamentação sobre dispositivos médicos, a outra não.

O que faz a diferença é o texto descritivo na loja de aplicações. A primeira diz "dá informação sobre possíveis situações com base nos seus sintomas". A segunda diz "avalia os seus sintomas e mostra o diagnóstico provável". Esta segunda frase transforma o produto num produto apresentado com fins de diagnóstico, e com isso entram em jogo a classificação de risco, a avaliação da conformidade, o processo técnico, a avaliação clínica e as obrigações de vigilância pós-comercialização.

Este é o erro mais dispendioso e mais facilmente evitável que vejo em projetos de tecnologia de saúde. A descrição do produto é escrita pela equipa de marketing, ninguém pensa na sua consequência jurídica, e o produto acaba a entrar num regime de conformidade que nunca se pretendeu assumir.

A finalidade de uso é um texto jurídico

A regra prática que daqui resulta é a seguinte. A descrição do produto deve ser redigida com o mesmo cuidado que uma política de privacidade e passar por uma revisão jurídica antes de ser publicada.

Essa revisão não deve limitar-se à descrição da loja. O título no site, a frase no vídeo promocional, a afirmação na apresentação comercial e o texto no documento de apoio podem produzir o mesmo resultado. Se num sítio disse "diagnostica", escrever noutro "é apenas informativo" não retira essa declaração.

A decisão tem de ser tomada desde o início. Se o produto vai ser um dispositivo médico, o processo exigido por esse regime é montado desde o início e entra no plano como uma rubrica de custo. Se não vai ser, manter esse limite em cada texto deve tornar-se uma regra de desenvolvimento do produto.

A arquitetura de acesso aos dados de saúde

O artigo 6.º da Lei 6698 considera os dados de saúde como categoria especial de dados pessoais e sujeita o seu tratamento a condições mais restritas. A tradução técnica desta qualificação fica incompleta na maioria dos projetos.

O quadro que vejo com frequência é este. A aplicação funciona, os dados são guardados, mas no sistema toda a gente pode ver tudo. O programador consegue aceder à base de dados de produção, a equipa de apoio consegue abrir o registo do paciente, a pessoa gestora consegue ver dados em bruto nos relatórios. Isto significa que o acesso não está limitado, e é difícil de defender numa auditoria.

A configuração correta começa pelo controlo de acesso baseado em funções, mas não termina aí. Cada acesso deve ficar registado, esse registo deve mostrar quem o fez e com que finalidade, e um acesso fora do habitual deve poder ser detetado. Se alguém abre o registo de um paciente a meio da noite, isso tem de ser visível no sistema.

O ambiente de testes é uma questão à parte. Testar com dados reais de pacientes é o hábito mais comum e mais arriscado na tecnologia de saúde. Trabalhar com dados mascarados ou sintéticos elimina em grande medida esse risco e não é tecnicamente difícil de implementar.

Apoio clínico à decisão e responsabilidade

Os sistemas de apoio à decisão com inteligência artificial levantam a questão de quem é responsável. Na prática, a configuração segura é a de o sistema produzir uma recomendação e a decisão final ficar a cargo do profissional de saúde competente.

Para que esta configuração não fique apenas no papel, é preciso manter em conjunto três registos. A recomendação produzida pelo sistema, os dados em que essa recomendação se baseia, e a decisão final tomada pelo profissional de saúde. Se os três forem guardados separadamente, não podem depois ser cruzados; se não forem guardados de todo, não é possível demonstrar onde está a responsabilidade.

Vale a pena acrescentar aqui um indicador. Deve acompanhar-se a taxa com que o profissional de saúde rejeita a recomendação do sistema. Se essa taxa se aproximar de zero, a supervisão humana tornou-se formal, e nesse ponto é de facto o sistema que toma a decisão. Esta constatação pode ser determinante numa discussão de responsabilidade.

Os serviços de saúde à distância

Os serviços de saúde à distância são regidos pela regulamentação do Ministério da Saúde. Que serviços podem ser prestados à distância, as obrigações de registo e os limites do serviço são definidos em regulamentação secundária. Como essa regulamentação pode mudar ao longo do tempo, ao conceber o produto é preciso consultar o texto em vigor.

O princípio que não muda é este. As situações que exigem observação presencial não podem ser resolvidas à distância. Uma aplicação de saúde à distância deve conseguir reconhecer e reencaminhar um pedido que exceda esse limite. O sistema conseguir dizer "para esta situação, consulte por favor um médico" não é uma funcionalidade de usabilidade, é uma exigência jurídica.

Ao iniciar um projeto

Nos projetos de tecnologia de saúde, a pergunta que tem de ter resposta na primeira reunião não é o que o produto vai fazer, mas o que vai declarar que é. Cada linha de código escrita sem esta pergunta ter resposta pode ter sido escrita segundo o regime errado.

A segunda pergunta diz respeito ao modelo de dados. Que dado é realmente necessário, quem poderá vê-lo, onde será registado o acesso e o que acontecerá quando a finalidade terminar. A resposta a estas quatro perguntas determina diretamente o desenho das tabelas, e alterá-lo depois, por exigir migrar dados de pacientes já existentes, gera um problema tanto técnico como jurídico.