Auditor de Conformidade FDA para MedTech

Visão Geral

Esta habilidade auxilia um revisor qualificado de qualidade/regulatório de dispositivos médicos; ela não confere certificação de auditor ou aprovação da FDA. O foco é em Software como Dispositivo Médico (SaMD) e regulamentações de equipamentos médicos tradicionais, incluindo 21 CFR Parte 820 (QMSR atual; requisitos históricos do QSR devem ser datados), IEC 62304 (Ciclo de Vida de Software), ISO 13485 e ISO 14971 (Gerenciamento de Riscos).

Quando Usar Esta Habilidade

• Use ao revisar Protocolos de Validação de Software para Dispositivos Médicos.
• Use ao auditar um Arquivo de Histórico de Design (DHF) para uma ferramenta de diagnóstico baseada em software.
• Use ao garantir que a infraestrutura de TI atende aos requisitos da 21 CFR Parte 11 para registros eletrônicos.
• Use ao preparar uma CAPA (Ação Corretiva e Preventiva) para um defeito de software.

Como Funciona

1. Ative a Habilidade: Mencione @fda-medtech-compliance-auditor e forneça o documento que você deseja revisar.
2. Especifique o Padrão: Indique se o foco é na Parte 820, Parte 11, ISO 13485, ISO 14971 ou IEC 62304.
3. Receba os Achados: A IA gera achados de auditoria específicos categorizados por gravidade (Principal, Menor, Oportunidade de Melhoria) com citações regulatórias.
4. Orientação para Correção: Obtenha passos acionáveis para resolver cada achado e fortalecer sua prontidão para auditoria.

Exemplos

Exemplo 1: Revisão da Causa Raiz de CAPA

Cenário: Uma CAPA foi aberta para um defeito de software em um dispositivo Classe II. A causa raiz documentada é “erro do desenvolvedor — requisitos pouco claros”. A ação corretiva é o retreinamento do desenvolvedor.

Achado:

FDA AUDIT FINDING
Severity: Major
Reference check: determine applicable current QMSR/ISO 13485 CAPA requirements; legacy 820.100(a)(2) is historical, not a current standalone citation

Analysis:
"Developer error" is a symptom, not a root cause. Retraining alone does not demonstrate that recurrence risk was addressed.
The record is insufficient to establish the true root cause; investigate
requirements, process controls and human factors without preselecting a conclusion.

Required Actions:
1. Perform a 5-Whys or Fishbone analysis targeting the requirements
   gathering and review process.
2. Update the SRS (Software Requirements Specification) and the
   corresponding process SOP.
3. Document an effectiveness check with a measurable criterion
   (e.g., zero requirements-related defects in next 3 releases).
4. Do not close the CAPA on retraining alone.

Melhores Práticas

• ✅ Faça: Forneça a redação exata de SOPs, tabelas de risco ou planos de validação para a revisão mais precisa.
• ✅ Faça: Espere interpretações rigorosas — o objetivo é encontrar fraquezas antes que um inspetor real o faça.
• ❌ Não faça: Esqueça de vincular cada defeito de software a um item de risco clínico em seu arquivo de risco ISO 14971.
• ❌ Não faça: Assuma que “nós testamos e funciona” satisfaz os requisitos de verificação de software da IEC 62304.

Limitações

• O QMSR da FDA entrou em vigor em 2 de fevereiro de 2026 e incorpora a ISO 13485:2016. Determine a data da regra, a aplicabilidade do dispositivo/jurisdição e as edições exatas dos padrões controlados antes de citar cláusulas; não reutilize uma citação supersedida da Part820.100 como lei atual.
• Esta é uma assistência de revisão, não certificação, prova de segurança clínica ou aconselhamento jurídico. Achados/notas requerem evidências reais e avaliação qualificada. Nunca autorize a liberação de produto, altere um arquivo de risco/CAPA, suprima um defeito ou reivindique conformidade com a FDA a partir do modelo; proteja dados confidenciais de pacientes/dispositivos.
• Não trate a saída como substituta para validação específica do ambiente, testes ou revisão de especialistas.
• Pare e peça esclarecimentos se os inputs, permissões, limites de segurança ou critérios de sucesso necessários estiverem faltando.