Dispositivos médicos: do requisito à operação

O dispositivo liga, apresenta uma leitura e transmite informação. A demonstração é importante, mas ainda não responde às perguntas de quem vai utilizar, adquirir, manter ou responder pelo produto. Funcionar uma vez não demonstra funcionamento consistente nas condições de uso pretendidas.

Desenvolver um dispositivo médico exige transformar uma necessidade em requisitos, controlar riscos, produzir evidência e sustentar a configuração entregue. Hardware, firmware, software, acessórios, instruções e condições de operação precisam ser examinados como partes de um sistema.

Este guia organiza perguntas para gestores, equipes de desenvolvimento, engenharia clínica e compradores. Não atribui classificação ou situação regulatória a um produto específico e não substitui a avaliação técnica, ética e regulatória aplicável.

O uso pretendido orienta o projeto

Antes de discutir sensores ou recursos, descreva o que o dispositivo se destina a fazer, para quem, por qual usuário e em qual ambiente. Uma medição, um alerta e uma recomendação podem envolver finalidades e consequências diferentes. A comunicação comercial não deve ampliar o uso além do que foi avaliado e sustentado.

A RDC nº 751/2022 trata da classificação de risco, dos regimes de regularização e dos requisitos de rotulagem e instruções de uso de dispositivos médicos. O enquadramento depende das regras aplicáveis ao uso pretendido e às características do produto. Fonte: Anvisa, RDC nº 751/2022.

Essa discussão precisa acontecer no início e ser revista diante de mudanças relevantes. Não é uma formalidade para encaixar depois uma solução já anunciada. Se houver software como dispositivo médico, seu enquadramento também exige análise específica; a RDC nº 657/2022 trata de sua regularização. Fonte: Anvisa, RDC nº 657/2022.

Um requisito precisa permitir uma verificação

“Ser fácil de usar” descreve uma intenção. O projeto precisa transformá-la em situações, usuários, tarefas e critérios que possam ser examinados. O mesmo vale para precisão, autonomia, comunicação, resistência, limpeza, manutenção e recuperação de falhas.

Propomos que cada requisito tenha origem, justificativa, critério de aceitação, método de avaliação e evidência associada. Quando um requisito muda, a equipe deve identificar quais testes, documentos e componentes são afetados.

Em um exemplo fictício de comunicação, não basta demonstrar o envio quando a rede está disponível. É necessário examinar o comportamento definido durante interrupção, reconexão e recuperação, inclusive o que o usuário consegue perceber e o que fica registrado. O requisito deve delimitar a resposta esperada; a apresentação não pode completar com uma promessa o que não foi testado.

Risco acompanha o ciclo, não apenas a reunião inicial

Uma análise de risco precisa orientar decisões sobre projeto, uso, informação e controle. Se a equipe registra um risco, mas não consegue mostrar como ele influencia o produto e os testes, o documento está desconectado da execução.

Perguntas úteis incluem: que situação pode levar ao dano, como seria percebida, qual controle foi escolhido e como se verifica sua efetividade? A resposta deve considerar uso esperado e situações previsíveis, sem presumir que treinamento corrige qualquer dificuldade de projeto.

A RDC nº 665/2022 organiza requisitos de boas práticas que incluem controles de projeto, verificação, validação, transferência e mudanças. O texto normativo deve ser consultado na versão aplicável; uma lista editorial não substitui seus requisitos. Fonte: Anvisa, RDC nº 665/2022.

Verificação e validação não são a mesma pergunta

Na leitura de gestão proposta aqui, verificação pergunta se os resultados do projeto atendem aos requisitos definidos. Validação examina se o produto atende às necessidades do usuário e ao uso pretendido, sob condições adequadamente definidas. A profundidade e os métodos dependem do produto e das exigências aplicáveis.

Evidência não pode ser emprestada de uma versão diferente sem análise. Se o sensor, o algoritmo, o acessório ou o uso muda, é preciso avaliar o impacto da alteração. A extensão de uma conclusão deve ser justificada, não presumida.

Pesquisa com pessoas exige um caminho próprio

Nem toda atividade de avaliação tem a mesma natureza. Teste de bancada, avaliação de usabilidade, investigação clínica e acompanhamento de uso respondem a perguntas diferentes e podem envolver obrigações distintas.

Antes de iniciar uma atividade com pessoas ou dados identificáveis, os responsáveis precisam determinar o protocolo, as aprovações necessárias, a proteção dos participantes e as condições de tratamento das informações. Um acordo comercial ou a concordância informal de uma equipe não substitui essa avaliação.

Na comunicação dos resultados, declare população, período, configuração, método e limitações. Uma medida de desempenho técnico não deve ser apresentada como desfecho clínico, e um resultado observado em um contexto não é uma garantia para outro.

Transferir para produção é preservar conhecimento

O protótipo pode depender da habilidade de quem o montou. A produção exige que especificações, materiais, fornecedores, montagem, inspeção e testes possam ser executados e conferidos de forma consistente.

Pergunte o que acontece quando um componente deixa de estar disponível. Como a alternativa é avaliada? Que documentos mudam? Quem aprova? Como as unidades e versões permanecem rastreáveis? A resposta não deve se limitar a dizer que a peça é semelhante.

Manutenção e reposição também fazem parte da experiência do comprador. O projeto precisa considerar como uma falha é identificada, como o serviço continua e como a configuração correta retorna ao uso. O alcance dessas atividades deve estar claro nos documentos e compromissos aplicáveis.

A operação em campo devolve evidência ao desenvolvimento

Relato sem apuração não deve virar conclusão executiva. A equipe precisa investigar, documentar o que sabe, separar hipóteses e comunicar o próximo passo. Ignorar documentação, repetir testes sem recuperar resultados anteriores ou anunciar uma correção sem verificar seu efeito compromete o conhecimento que deveria sustentar o produto.

Uma ocorrência precisa chegar à equipe responsável com informação suficiente para investigação, preservando dados pessoais e registros pertinentes. Que versão estava em uso? Em quais condições? O comportamento pode ser reproduzido? Qual foi a consequência e que medida de contenção foi adotada?

Não é aceitável encerrar uma investigação apenas porque o total da operação parece normal. Um problema localizado pode coexistir com indicadores agregados estáveis. Também não é correto atribuir todo relato à tecnologia sem examinar contexto e evidência.

O aprendizado deve voltar para requisitos, riscos, documentação, treinamento e controle de mudanças. O desenvolvimento continua responsável pela coerência entre o que o produto faz, o que seus documentos orientam e o que a comunicação afirma.

O que um comitê deve pedir antes de concluir

Peça uma descrição do uso e da configuração, requisitos relevantes, evidências que sustentam as afirmações, situação regulatória verificável quando aplicável, condições de implantação e responsabilidades de suporte. Identifique lacunas e quem pode resolvê-las.

O objetivo não é transformar o comprador em fabricante, mas permitir que cada responsável avalie sua parte com clareza. Para uma visão complementar, leia maturidade além do TRL e do piloto à contratação. Tecnologia de saúde precisa chegar à operação com conhecimento preservado, limites explícitos e capacidade de continuidade.