Voltando à postar de depois de alguns anos!
Na semana passada, participei de um evento muito interessante, o Summit Saúde Mental Digital: Inovação e Validação, promovido pelo Centro de Pesquisa e Inovação em Saúde Mental (CISM) do Instituto Nacional de Psiquiatria do Desenvolvimento para Crianças e Adolescentes (INPD). Vejam mais informações gerais sobre o evento aqui: https://inpd.org.br/cism-une-diferentes-atores-para-debater-desenvolvimento-validacao-e-fomento-de-solucoes-digitais-em-saude-mental/).
O evento incluiu diversas apresentações e mesas-redondas, e minha participação foi focada em explicar o conceito de Software como Dispositivo Médico (Software as a Medical Device – SaMD) e suas implicações para o desenvolvimento de colocação no mercado de software de saúde mental. Além disso, participai da mesa-redonda focada em aspectos regulatórios. Como sempre, houve grande interesse no assunto e não houve tempo para responder à todos os questionamentos da maneira correta, por isso, achei interessante expandir os comentários neste post.
O termo Software as a Medical Device (SaMD) foi criado originalmente na primeira reunião do grupo de trabalho de software do IMDRF, em 2012, na qual participei junto à ANVISA representando a indústria brasileira. Antes disso, o termo geralmente usado era “software standalone”, mas esse termo era confuso para quem da área de engenharia de software (e uma boa parte dos “novos” desenvolvedores de SaMD não vem da área de dispositivos médicos, o que criar uma grande barreira/dificuldade. Este tópico foi inclusive abordado no terceiro documento do grupo do IMDRF (e último que eu participei diretamente) IMDRF/SaMD WG/N23 – Software as a Medical Device (SaMD): Application of Quality Management System).
Aproveitando, os documentos do IMDRF sobre SaMD podem ser encontrados neste link, e todos são essenciais para se entender as expectativas regulatórias atuais sobre SaMD 0 https://www.imdrf.org/working-groups/software-medical-device-samd. Vou citar alguns deles de maneira recorrente neste post.
O principal ponto da minha apresentação foi explicar o que é um SaMD. Para isso, primeiramente é necessário o entendimento do que é um dispositivo médico.
Costumo falar que um dispositivo médico vai desde uma camisinha até uma ressonância magnética. Quando entrei na área em 2001, o “número mágico” de tipos de dispositivo médico existentes era mais ou menos 10.000. Hoje em dia este número mágico é de mais de 20.000 tipos diferentes! Uma característica básica dessa grande gama de dispositivos é que cada um pode ter características (físicas, químicas, biológicas) totalmente diferentes. Isso criar uma dificuldade, em particular do ponto de vista regulatório, de se ter regulamentações específicas para os diferentes tipos. Por isso, o que temos são regulamentações básicas gerais, de alto nível, que abordam QUALQUER dispositivo médico, como a RDC 751/2022, que define os requisitos para registro de dispositivo médicos, assim como a RDC 848/2024, que define os requisitos essenciais de segurança e eficácia de dispositivos médicos. Estas regulamentações são aplicadas a TODOS os dispositivos médicos. Algumas regulamentações são específicas, como a RDC 657/2022 que dispõe especificamente sobre a regularização de SaMDs. Lembro aqui que é responsabilidade de quem vai colocar o dispositivo médico no mercado identificar todas as regulamentações aplicáveis e atende-las.
A ANVISA mantém uma lista de todas as regulamentações vigentes por assunto no link Bibliotecas temáticas. No caso de dispositivos médicos, as regulamentações estão na parte de “Produtos para a saúde” (que, assim como “correlatos”, é um termo antigo que designa o que é um “medical device” do termo original em inglês). Há também algumas regulamentações aplicáveis na parte de “Temas Transversais”, como a regulamentação para obter a Autorização de Funcionamento da Empresa (AFE).
Nem tudo que se usa em um hospital ou ambiente de cuidados à saúde é um dispositivo médico. Um dispositivo médico é definido legalmente na RDC 751/2022. A figura acima mostra a definição e alguns destaques.
Resumindo, um dispositivo médico é produto (que inclui software) que é destinado a ser usado em seres humanos para certos propósitos médicos.
O “destinado” aqui é importante, pois, embora a ANVISA defina o que é (em geral) um dispositivo médico no Brasil, quem realmente define se um produto X é um dispositivo médico é seu fabricante/detentor de notificação ou registro (são os entes responsáveis pela colocação do dispositivo médico no mercado, e responsáveis por usa segurança e eficácia perante a lei), quando coloca (em particular nas instruções de uso) para qual fim seu produto deve ser usado. Se o que o fabricante descreve um uso que se encaixa na definição de dispositivo médico, este produto passa a ser um dispositivo médico e portanto DEVE ser regularizado para ser usado em seres humanos / entrar no mercado de maneira legal.
Com isso em mente, o que é um SaMD? Um SaMD é um software que não precisa de um hardware de dispositivo médico para atuar (ele pode funcionar, por exemplo, em um computador comum) E atende alguma das definições de um dispositivo médico.
Os software para saúde mental geralmente vão se encaixa no propósito médico definido em a), ou seja diagnóstico, prevenção, monitoramento, tratamento ou alívio de uma doença (transtornos mentais são considerados doenças).
Ou seja, se o software pode ser usado em um computador qualquer, ou smartphone ou tablet, e sua função é, por exemplo, diagnosticar depressão, ele passa a ser um SaMD e precisa ser regularizado.
Aqui já entram algumas considerações. Em particular no caso de softwares, definir se ele realmente se encaixa no diagnóstico, prevenção, monitoramento, etc., pode não ser tão óbvio. Muita gente pensa que se o software não “falar” diretamente qual o problema, não é um diagnóstico. Mas isso não é verdade. Por exemplo, muitos softwares na área de saúde mental fornecem algum tipo de “score” baseado em questionários clínicos. Se o software pega informações e conclui sobre “score”, ele está dando um diagnóstico. Este é um exemplo simples e comum de como se analisar o uso de um software, mas existem muitos outros exemplo mais complexos.
Outro ponto importante, e que muitos desenvolvedores/empresas pensam que é uma forma de não precisar regularizar o software, ou se eximir de responsabilidades, é indicar que o software só fornece uma informação geral, mas que o diagnóstico final deve ser fornecido por um profissional de saúde. Neste caso o software continua sendo um SaMD e precisa ser regularizado, mas o que acontece é que provavelmente sua classe de risco (comento sobre isso mais abaixo) vai ser menor, o que leva a ter que atender, de maneira geral, a menos requisitos regulatórios. Mas deve-se tomar cuidado: se o software, sozinho, leva a um diagnóstico direto para o paciente (por exemplo, um app de celular que informa o estado mental do paciente0, e não há envolvimento de nenhum profissional da saúde no meio do cuidado, apenas ter uma linha no manual de usuário indicando que o software não faz diagnóstico e que o diagnóstico “real” é feito por um médico não é suficiente. É necessário que essa situação fique bem clara na definição de uso pretendido e nas informações de marketing do produto.
Este último ponto também é importante para entender que, embora o fabricante defina se seu produto é um dispositivo médico ao declarar sua finalidade prevista, a ANVISA tem a autoridade para exigir que um produto seja um dispositivo médico se achar que o produto faz se encaixa de definição de dispositivo médico, mesmo que o fabricante não declare seu uso de uma forma que fique claro que ele é um dispositivo médico. Isso acontece também no caso de um produto não ter seu uso declarado como dispositivo médico, mas seu material de marketing indicar que o uso no final das contas se encaixa como dispositivo médico.
Uma das bases para a regulamentação de dispositivo médicos no Brasil (que é baseada historicamente nos requisitos para dispositivos médico na Europa) é a classificação de risco, que usa uma série de 22 regras (definidas na RDC 751/2022) para separar os dispositivos entre 4 classes de risco distintas:
I – Classe I: baixo risco;
II – Classe II: médio risco;
III – Classe III: alto risco; e
IV – Classe IV: máximo risco.
A ANVISA tem dois processos para regularização de dispostos médicos no Brasil. A “notificação”, processo simplificado, se aplica a dispositivos de classe de risco I e II. O “registro”, processo completo, se aplica a dispositivos de classe de risco III e IV. O “registro” tem mais requisitos a serem atendidos, inclusive para submissão de documentação para comprovação tanto da “segurança e eficácia” do disposto médico (baseado no atendimento da RDC 848/2024) assim como do atendimento, pelo fabricante, das Boas Práticas de Fabricação (baseado no atendimento da RDC 665/2022 e na expedição de um Certificado de Certificado de Boas Práticas de Fabricação (CBPF) pela RDC 687/2022).
O framework para categorização de risco para SaMD usa a regra 11 da RDC 751/2022 da ANVISA em conjunto com a tabela de caregorização do documento IMDRF/SaMD WG/N12FINAL:2014 – “Software as a Medical Device”: Possible Framework for
Risk Categorization and Corresponding Consideration do IMDRF.
Seguem alguns exemplos práticos para software relacionados a depressão (retirados do documento Europeu – MDCG 2019-11 – Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR – embora o documento seja relacionado à regulamentação Européia, como nossa regulamentação e regras são baseadas nos regulamentos Europeus, uma boa parte das orientações Européias pode ser usada no Brasil, mas cuidado que esse uso exige uma verificação inicial de que a orientação está relacionada à um requisito igual no Brasil):
Exemplo de classificação de risco 1 – SaMD de terapia cognitiva que inclui uma função de diagnóstico que se destina a dar feedback ao software para determinar a terapia de acompanhamento, por exemplo, o software adapta o tratamento da depressão com base no feedback diagnóstico, deve estar na classe III conforme a Regra 11 b). Quando um especialista
determina a terapia cognitiva necessária com base no resultado fornecido pelo SaMD conforme definido na finalidade pretendida, o SaMD seria classificado como classe II conforme a Regra 11.
- Categoria de Risco II.ii do IMDRF, pois a situação da assistência médica é séria e a significância
das informações é “conduzir o gerenciamento clínico”.
Exemplo de classificação de risco 2 – SAMD diagnóstico destinado a pontuar (“score”) a depressão com base em dados inseridos sobre os sintomas de um paciente (por exemplo, humor, ansiedade) deve ser classificado como classe III sob a Regra 11 b)
- (Categoria de Risco III.ii do IMDRF) pois a situação de saúde (depressão) é grave e o significado da informação é “diagnóstico”).
É reconhecido que a definição da finalidade pretendida para um SaMD é normalmente um pouco mais difícil de ser criada do que para um dispositivo médico comum. Uma das melhores formas de se criar tal finalidade é seguir uma orientação do MHRA do Reino Unido (mais informações neste link: https://www.gov.uk/government/publications/crafting-an-intended-purpose-in-the-context-of-software-as-a-medical-device-samd/crafting-an-intended-purpose-in-the-context-of-software-as-a-medical-device-samd)
Dispositivos médicos tratam de aspectos relacionados à saúde e são usado diretamente em pacientes, o que faz com que sejam considerados mais “perigosos” que a maioria dos produtos.
Todos os produtos colocados no mercado devem atender a algum tipo de regulamentação mínima, mas a maioria dos produtos precisa apenas atender a regulamentações gerais e genéricas. Dispositivos médicos, pelo fato de serem considerados mais “perigosos”, são altamente regulados. Por causa disso, há muitas regulamentações específicas que se aplicam a dispositivos médicos. Isso significa que, para legalmente realizar atividades com tais dispositivos e para usar os mesmos em seres humanos, além de colocá-los e mantê-los no mercado, é necessário atender a estas regulamentações.
É importante ressaltar: se o software é um SaMD, ele deve ser regularizado na ANVISA – isso não é opcional, é um requisito legal obrigatório!
De maneira geral, há 3 focos no controle regulatório governamental, e, portanto, para a regulamentação governamental de dispositivos médicos:
- 1 – O dispositivo médicos em si (incluindo a demonstração de segurança e eficácia do mesmo, assim como o controle de sua fabricação)
- 2 – A representação do dispositivo médico para o paciente e usuário
- 3 – O uso do dispositivo médico
De maneira geral, essas vertentes e controles relacionados são mostrados na imagem a seguir:
O “fabricante / detentor de notificação ou registro” é o responsável legal pelo dispositivo médico, e portanto, também é o responsável pelo atendimento à regulamentação. O SaMD deve ser projetado de maneira a poder ter sua segurança demonstrada (de maneira geral, isso significa atender à RDC 848/2024 que define os requisitos essenciais de segurança e desempenho aplicáveis aos dispositivos médico e as normas relacionadas, como a ISO 14971 (que trata de gerenciamento de risco), ISO 62304 (que trata de processos de ciclo de vida de software) e ISO 62366-1 (que trata de usabilidade). Além disso, o SaMD deve ser fabricado atendendo às Boas Práticas de Fabricação (RDC 665/2022) e, para poder ser usado em seres humanos e colocado no mercado, deve atender as regulamentações de notificação/registro (RDC 751/2022, de notificação e registro geral de dispositivos médicos, e RDC 657/2022, específica para a regularização de SaMD).
Como parte do processo de projeto e demonstração de segurança e eficácia, é necessário realizar atividades de verificação (normalmente ensaios internos que demonstram o atendimento a certos requisitos) e validação (análise de dados e possível uso em pacientes para demonstrar que o produto é eficaz em realizar sua finalidade destinada). Na área de dispositivos médicos, a “validação”é entendida como a realização da chamada “avaliação clínica”, que nada mais é que um processo específico de análise de dados baseado no conceito de “revisão sistemática”.
Dependendo da finalidade pretendida do SaMD, pode ser necessário o uso do mesmo em pacientes para a obtenção de dados para a avaliação clínica. Se isso for necessário ANTES da notificação/registro do produto, ele só pode ser usado se primeiramente for demonstrado que ele é seguro para uso humano. No caso de produtos sob registro (classes III ou IV), é necessário uma aprovação prévia da ANVISA (que é o órgão regulador de investigações clínicas / ensaios clínicos de dispositivos médicos) de acordo com a RDC 837/2023. Para dispositivos sob notificação (classes de risco I e II), apenas o consentimento do sistema CEP/CONEP é suficiente pois a ANVISA não requer uma aprovação prévia (de qualquer maneira, é necessário garantir que o dispositivo médico é seguro, e esta responsabilidade fica inteiramente com o fabricante / detentor de notificação ou registro”.
Um ponto importante: os regulamentos da ANVISA tratam apenas das etapas de “industrialização”de dispositivos médicos. Para isso, é necessário que estas atividades sejam feitas por um “fabricante / detentor de notificação ou registro” legalizado (que possua a chamada Autorização de Funcionamento da Empresa – AFE – para as atividades relacionadas, de acordo com a RDC 16/2014) . Por exemplo, para se requerer a aprovação para uma investigação clínica, é esta entidade que vai fazer tal requisição (e é a mesma entidade que vai requerer a “notificação/registro”no futuro).
A principal preocupação regulatória é com a segurança do dispositivo durante o uso, além da eficácia em fazer o que se destina. Do ponto de vista de segurança, isso significa identificar todos os riscos conhecidos que podem ocorrer durante o uso do dispositivo. Este processo é chamado de “gerenciamento de risco” e deve ser aplicado seguindo a norma ISO 14971.
Outro aspecto é o projeto em si, que deve ser controlado em detalhes. No caso de SaMDs, isso significa em particular atender aos requisitos de processo de desenvolvimento definidos na IEC 62304.
Finalmente, um outro aspecto necessário é a usabilidade, que deve seguir o processo definido na IEC 62366-1.
Esta foi apenas uma reflexão geral sobre o que eu mostrei na palestra do Summit. Em um post futuro entrarei em mais detalhes sobre estes tópicos e também sobre as documentações que se espera que sejam criadas para demonstrar o atendimento aos requisitos regulatórios.
Comentários