• The device must be safe and effective
• The device must not compromise the health or safety of the patient, user, or others

For the above two aspects to be true, it is also necessary that:

• The potential risks must be compatible with a high degree of health and safety protection, given the current generally recognized state of knowledge
• The potential risks associated with the use of the device must be acceptable when balanced against the expected clinical benefits that the device provides to the patient (seen in another way, the clinical benefits must “outweigh” the potential risks)

For a manufacturer to be able to demonstrate the above, they must, in general:

• Define what it means to be safe for their device
• Define what it means to be effective for their device
• Define and measure the expected clinical benefits of their device
• Define and estimate the potential risks associated with the use of their devices
• Design the device so that any risks associated with its use are compatible with a high level of health and safety protection in accordance with generally recognized knowledge, i.e., the device cannot in principle be more dangerous than similar devices or alternative clinical solutions for the same clinical problem currently on the market
• Compare the expected clinical benefits with the estimated potential risks, including the way in which the device was designed to control such risks, and conclude whether the expected benefits “outweigh” the potential risks

With this in mind, it is important to remember that the entire process related to transforming an idea to solve a clinical need into an industrialized medical device is known as design (or engineering design, using the most common technical term).

• The design process must include the so-called design inputs, design outputs, design verification and validation steps, among others (the related requirements are normally known as “design control”). Furthermore, it includes or interfaces with any other process that performs some activity related to design, such as risk management in general, the usability engineering process, biological safety assessment (biocompatibility) or clinical evaluation

When defining the so-called “design inputs” (which are the requirements that the product must meet), the manufacturer must define various requirements, such as safety requirements, performance requirements, usability requirements, marking requirements, packaging requirements, etc. In addition, he must also decide how to verify that these requirements are met (by bench tests, on animals, or another type of evaluation).

• In order to define these design requirements, it is common for manufacturers to analyze both the history of the clinical problem and similar devices on the market, including their evolution. I do not know of a manufacturer that has not done this in some way, even if simple. On the other hand, this assessment is precisely an assessment of the current state of generally recognized knowledge. Most of the time, this assessment is done before the project is even started, as part of the project feasibility analysis
• In the case of clinical benefits, this analysis should also be one of the first activities of a project; in the case of safety requirements, these must be identified, in addition to the aforementioned analysis, also by applying the risk management process

The risk management process is the process that analyzes (identifies potential risks), evaluates (concludes whether the risks are acceptable or not), controls (defines how to control unacceptable risks) and monitors (the acceptability of all) potential risks of using the device. The risk management process can be understood as a decision-making process, not an implementation process. For example, identifying potential risks primarily uses the analyses made during the design, including in particular the design inputs, to conclude which risks may arise from the use of the device. Even in the case of risk controls defined in risk management, the one who actually implements the controls is the more general design process.

• The risk management process in general does not include a process for identifying, measuring and concluding on clinical benefits. Although a standard such as ISO 14971 includes some possibilities related to the justification of certain risks versus benefits (this is another historical confusion that may be expanded in the future), these benefits should be identified and measured in a separate process. The so-called “benefit/risk determination” of the device as a whole is therefore a general design activity

The clinical evaluation process is a process of generating, collecting, analyzing and determining clinical data on the device (which is defined as safety or efficacy data that comes from the clinical use of the device in humans). And where do the definitions of what data will be generated, collected, analyzed and determined come from? Again, from the more general design process. In other words, the clinical evaluation process (which is nothing more than a specific implementation of the scientific research process called “systematic review”) deals only with data, but it does not define the data itself, it uses the data pre-defined in stages of the device design.

• As a specific example, regulations such as European Regulation 745/2017 (MDR) require that the clinical evaluation plan of the device specify the intended purpose of the device and detail benefits and other parameters. This information does not come from the clinical evaluation. It comes from the design (and a good part of the design input requirements) of the device

Finally, a comment on the issue of state of the art, state-of-the-art, or whatever term you want to use to demonstrate the “consensus” level of current knowledge.

We do not have a definition of the term in medical device regulations (we currently have a definition in ISO 14971 which was created based on a definition from another ISO/IEC standard). For example, in the European Regulation 745/2017 (MDR), there are 12 instances of the term “state of the art”. Most of these 12 instances indicate that the requirements should be applied “considering”, “based on”, “in the context of” the state of the art. None of these requirements indicate that products have to BE state of the art. What’s the reason?

One of the reasons is that the determination of whether or not a product IS “state of the art” cannot be made solely by a company, a notified body, or even a regulator. Something “BEING” state of the art implies that a wide range of stakeholders agree (consensus) that something is state of the art. Even technical standards, which are agreed upon (consensus) by those involved, are not considered to “be” state of the art, but to “reflect” the state of the art (an interesting discussion can be seen in item 3.5 of the MDCG 2021 document-5 Rev. 1 Guidance on standardization for medical devices).

In my experience, the only situation I know of where something is defined as “being” state of the art is in the context of a product liability lawsuit in which a company is being sued by a user who feels they have been harmed by a product. Even in this case, the court ruling can basically confirm whether a product “was” or “was not” state of the art when it was put on the market or used by the user (i.e. whether the manufacturer demonstrated that it did enough from a design and safety standpoint that the product was therefore not the cause of the problem).

What is the reason for the above comments? Well, it seems to me that many people today think that the “state of the art” (or the term SOTA) is something new, and that its analysis must be done in a very detailed and in-depth manner.

As I mentioned above, companies have always done, in one way or another, an analysis of the current knowledge to design their products. Furthermore, regulations indicate the need to “consider” and “base oneself on the “state of the art” in order to comply with regulations. No regulation that I am aware of requires that a SUPER DETAILED  ANALYSIS OF THE STATE OF THE ART be done, nor does it identify how any analysis should be done.

Therefore, I suggest being careful with indications that a complex analysis of the state of the art must be done in order to comply with regulations. They are not supported by regulatory requirements (unfortunately, certain current developments such as the upcoming ISO 18969 clinical evaluation standard seem to focus too much on having requirements for doing a complex state-of-the-art analysis, and too few requirements for the clinical evaluation/systematic review process itself).

The post Some thoughts on benefit/risk determination, design, clinical evaluation, risk management and state of the art of medical devices first appeared on SQR Consulting - Consultoria usando abordagens científicas para assuntos regulatórios de dispositivos médicos.

• Por diversas razões que eu não vou entrar neste post (mas posso expandir no futuro), os dois aspectos básicos definem se um dispositivo médico pode ser colocado e mantido no mercado são:
  • O dispositivo deve ser seguro e eficaz
  • O dispositivo não deve comprometer a saúde ou segurança do paciente,  usuário ou outros 

Para que os dois aspectos acima sejam verdadeiros, também é necessário que:

• Os eventuais riscos associados ao uso do dispositivo devem ser aceitáveis quando balanceados contra o benefício clínico que o dispositivo proporciona aos paciente (visto de uma outra maneira, os benefícios clínicos devem “pesar mais que” os eventuais riscos)
• Os eventuais riscos devem ser compatíveis com um elevado grau de proteção da saúde e da segurança, atendendo ao estado atual dos conhecimentos geralmente reconhecido

Para ser possível que um fabricante demonstre os acima, ele deve, de maneira geral:

• Definir o que significa ser seguro para seu dispositivo
• Definir o que significa ser eficaz para seu dispositivo
• Definir e medir os benefícios clínicos esperados de seu dispositivo
• Definir e estimar os eventuais riscos associados ao uso de seus dispositivos
• Projetar o dispositivo de maneira que os eventuais riscos associados ao uso sejam compatíveis com um elevado grau de proteção à saúde e segurança atendendo ao conhecimento geralmente reconhecido, ou seja, o dispositivo em princípio não pode ser mais perigoso que dispositivos similares ou soluções clínicas alternativas para o mesmo problema clínico, existentes atualmente no mercado
• Comparar os benefícios clínicos esperados com os eventuais riscos estimados, incluindo a maneira como o dispositivo foi projetado para controlar tais riscos, e concluir se os benefícios esperados “pesam mais que” os eventuais riscos

Com isso em mente, é importante lembrar que todo o processo relacionado a transformar uma idéia para resolver uma necessidade clínica em um dispositivo médico industrializável é conhecida como projeto (ou projeto de engenharia, usando o termo técnico mais comum).

• O processo de projeto deve incluir as chamadas entradas de projeto, saídas de projeto, etapas de verificação e validação de projeto, entre outros (os requisitos relacionados são normalmente conhecidos como “controle de projeto”). Além disso, ele inclui ou interfaceia com qualquer outro processo que realize alguma atividade relacionada a projeto, como o gerenciamento de risco em geral, o processo de engenharia de usabilidade, avaliação de segurança biológica (biocompatibilidade) ou a avaliação clínica)

Ao definir as chamadas “entradas de projeto” (que são os requisitos que o produto deve atender), o fabricante deve definir requisitos diversos, como por exemplo, requisitos de segurança, requisitos de desempenho, requisitos de usabilidade, requisitos de marcação, requisitos de embalagem, etc. Além disso, ele também deve decidir como verificar que esses requisitos são atendidos (por ensaios de bancada, em animais, ou outro tipo de avaliação)

• Para definir estes requisitos de projeto, é comum que os fabricantes analisem tanto o histórico do problema clínico, quanto dispositivos similares no mercado, incluindo a evolução dos mesmos. Desconheço um fabricante que não tenha feito isso de alguma maneira, mesmo que simples. Por outro lado, esta avaliação é exatamente uma avaliação do estado atual dos conhecimentos geralmente reconhecido. Na maior parte do tempo, esta avaliação é feita ainda antes do projeto ser iniciado, como parte da análise de viabilidade do projeto
• No caso dos benefícios clínicos, esta análise também deveria ser uma das primeiras atividades de um projeto; no caso de requisitos de segurança, os mesmos devem ser identificados, além da análise citada, também pela aplicação do processo de gerenciamento de risco

O processo de gerenciamento de risco é o processo que analisa (identifica os possíveis riscos), avalia (conclui se os riscos são aceitáveis ou não), controla (define a forma de controlar os riscos inaceitáveis) e monitora (a aceitabilidade de todos) os eventuais riscos de uso do dispositivo. O processo de gerenciamento de risco pode ser entendido como um processo decisório, não de implementação. Por exemplo, a identificação de possíveis riscos usa principalmente as análises feitas durante o projeto, incluindo em particular as entradas de projeto, para concluir quais riscos podem vir do uso do dispositivo. Mesmo no caso dos controles de risco definidos no gerenciamento de risco, quem realmente implementa os controles é o processo mais geral de projeto.

• O processo de gerenciamento de risco de maneira geral não inclui um processo de identificação, mensuração e conclusão sobre benefícios clínicos. Embora uma norma como a ISO 14971 inclua algumas possibilidades relacionadas à justificativa sobre certos riscos em comparação com benefícios (esta é outra confusão histórica que pode ser expandida no futuro), esses benefícios devem ser identificados, mensurados em um processo separado. A chamada “determinação benefício/risco” do dispositivo como um todo, portanto, é uma atividade geral de projeto

O processo de avaliação clínica é um processo de geração, coleta, análise e determinação de dados clínicos do dispositivos (que são definidos como dados de segurança ou eficácia que vem do uso clínico do dispositivo em seres humanos). E de onde vêm as definições de quais dados serão gerados, coletados, analisados e determinados? Novamente, do processo mais geral de projeto. Em outras palavras, o processo de avaliação clínica (que nada mais é que uma implementação específica do processo de pesquisa científica chamado de “revisão sistemática”) trata apenas de dados, mas ele não define os dados em si, ele usa os dados pré-definidos em etapas do projeto do dispositivo.

• Como exemplo específico, regulamentações como a Regulamentação Européia 745/2017 (MDR) requerem que o plano de avaliação clínica do dispositivo especifique o propósito pretendido do mesmo e detalhe benefícios e outros parâmetros. Estas informações não vem da avaliação clínica. Elas vem do projeto (e uma boa parte dos requisitos de entrada de projeto) do dispositivo.

Por fim, um comentário sobre a questão de estado da arte, estado-da-arte, ou o termo que se queira dar para demonstrar o nível “consensuado” do conhecimento atual.

Não temos uma definição do termo em regulamentações de colocação no mercado de dispositivos médicos (no momento, temos uma definição na norma ISO 14971 que foi criada baseada em uma definição de outra norma ISO/IEC). Por exemplo, a Regulamentação Européia 745/2017 (MDR) tem 12 instâncias do termo “estado da arte”. A maior parte destas 12 instâncias indicam que os requisitos devem ser aplicados “considerando”, “baseado no”, “no contexto do” estado da arte. Nenhum destes requisitos indica que os produtos têm que SER estado da arte. Qual o motivo?

Um dos motivos é que a determinação de se um produto É ou NÃO é “estado da arte” não pode ser feita apenas por uma empresa, um organismo notificado, ou mesmo um regulador. Algo “SER” estado da arte implica uma grande gama de interessados concorde que algo é o estado da arte. Mesmo normas técnicas, que são consensuadas pelos envolvidos, não são consideradas “serem” estado da arte, mas “refletirem” o estado da arte (uma discussão interessante pode ser vista no item 3.5 do documento MDCG 2021-5 Rev. 1 Guidance on standardisation for medical devices).

Pela minha experiência, a única situação que eu conheço em que algo é definido como “sendo” estado da arte é no contexto de uma decisão legal relacionada à responsabilidade de produto (product liability) dentro de um processo em que uma empresa está sendo processada por um usuário que acha que foi prejudicado por um produto. Mesmo neste caso, a decisão judicial basicamente pode confirmar se um produto “era” ou “não era” estado da arte quando colocado no mercado ou usado pelo usuário (ou seja, se o fabricante demonstrou que fez o suficiente do ponto de vista de projeto e segurança e que portanto o produto não seria a causa do problema).

Qual o motivo dos comentários acima? Bem, me parece que muita gente hoje tem achado que o “estado da arte” (ou o termo SOTA) é algo novo, e que a análise do mesmo deve ser feita de maneira mega detalhada e aprofundada.

Como comentei acima, as empresas sempre fizeram, de uma maneira ou de outra, uma análise do conhecimento do momento para projetarem seus produtos. Além disso, as regulamentações indicam a necessidade de “considerar” e “se basear no ”estado da arte” para atendimento regulatório. Nenhum regulamentação que eu conheça requer que seja feita uma MEGA ANÁLISE DO ESTADO DA ARTE, nem identifica como qualquer análise deve ser feita.

Portanto, sugiro tomar cuidado com indicações de que uma análise complexa do estado da arte deve ser feita para atender as regulamentações. Elas não tem respaldo nos requisitos regulatórios (infelizmente, certos desenvolvimentos atuais como a futura norma de avaliação clínica ISO 18969 parece focar demais em ter requisitos para se fazer uma análise complexa do estado da arte, e pouquíssimos requisitos para o processo de avaliação clínica/revisão sistemática em si).

The post Algumas reflexões sobre determinação benefício/risco, projeto, avaliação clínica, gerenciamento de risco e estado da arte de dispositivos médicos first appeared on SQR Consulting - Consultoria usando abordagens científicas para assuntos regulatórios de dispositivos médicos.

No final de 2024, 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.

The post Software como dispositivo médico (Software as a Medical Device – SaMD) – algumas reflexões, parte 1 first appeared on SQR Consulting - Consultoria usando abordagens científicas para assuntos regulatórios de dispositivos médicos.