Dispositivos médicos e RDC 665/2022: o eQMS que serve

A RDC 665/2022 trouxe BPF de dispositivos médicos alinhada à ISO 13485:2016. O que muda no eQMS — DHF, risco, vigilância — e onde fornecedor tradicional não atende.

A RDC 665/2022 redesenhou o BPF brasileiro de dispositivos médicos, alinhando explicitamente à ISO 13485:2016. Empresas que vinham operando com a antiga RDC 16/2013 tiveram que repensar o sistema de qualidade — e o eQMS que servia pra farma puro frequentemente não cobre o que dispositivos exigem.

Esse artigo destila as 5 áreas onde dispositivos têm exigência específica e o que isso significa pra escolha do eQMS.

1. Design History File (DHF)

Dispositivos exigem rastreabilidade completa do projeto: do design input até o design output, com todas as revisões, verificações e validações documentadas. É o DHF — Design History File.

O que o eQMS precisa entregar:

• Vínculo bidirecional entre requisitos, especificações e testes
• Registros de design review com assinatura formal
• Trace matrix viva, não documento estático
• Histórico de evolução de design preservado, não substituído

eQMS farma puro normalmente trata documento como entidade única — DHF exige modelo de design tree.

2. Análise de risco contínua (ISO 14971)

Risco não é evento único — é processo contínuo ao longo do ciclo de vida. ISO 14971:2019 + RDC 665 exigem:

• Análise inicial de risco
• Atualização a cada mudança de design
• Re-avaliação com base em dados pós-mercado
• Análise de risco residual aceito documentada

O que o eQMS precisa entregar: módulo de risco vivo, ligado a CAPA e a controle de mudança. Não tabela Excel anexa.

3. Vigilância pós-mercado e MDV

Dispositivos exigem coleta proativa de dados de campo, análise de tendência, e ações disparadas. O conceito de Medical Device Vigilance (MDV) virou parte explícita do BPF.

O que o eQMS precisa entregar:

• Workflow de notificação de evento adverso (com prazos regulatórios)
• Integração com reclamação → investigação → CAPA
• Tendência de problema de campo, segmentada por modelo/lote
• Geração de PSUR/PMS reports automatizada

4. UDI (Unique Device Identification)

Identificação única do dispositivo é exigência ascendente. Brasil ainda formalizando, mas mercados FDA e EU MDR já exigem.

O que o eQMS precisa entregar: rastreabilidade até nível de unidade vendida, com associação a histórico de produção, retenção, e reclamação.

5. Validação de software (Cat 5 do GAMP)

Dispositivos com software embarcado (SaMD — Software as a Medical Device, ou SiMD — Software in a Medical Device) exigem validação Cat 5, com SDLC formal, code review, testes unitários documentados. O eQMS precisa gerenciar o DHF do próprio software como artefato regulado.

O que muda em relação ao eQMS farma puro

Área	Farma puro	Dispositivos (RDC 665)
Documento	Versionado linear	Design tree com input/output
Risco	ICH Q9 (processo)	ISO 14971 (produto + processo)
Pós-mercado	Farmacovigilância	MDV + Vigilância de campo
Identificação	Lote	UDI + lote + serial

Onde os enterprise atendem (ou não)

MasterControl historicamente atende bem dispositivos (forte tradição em FDA QSR / ISO 13485). Veeva tem módulo específico mas pacote ainda em maturação. Players nacionais brasileiros raramente atendem dispositivos out-of-the-box.

Pra dispositivo médico de médio porte BR (10-150 funcionários), o caminho honesto é:

1. MasterControl (caro, mas atende) — TCO R$ 800k-2M ano 1
2. Plataforma vertical de dispositivos (Greenlight Guru, etc — geralmente em dólar)
3. NOAH OS com módulo dispositivos ativado (categoria 4 brasileira)

Como o NOAH atende

NOAH OS tem módulo dispositivos (Tier 2) com DHF + ISO 14971 + MDV configurados. Roteiro de validação adicional pra Cat 5 do software embarcado quando aplicável. Veja o panorama de fornecedores pra encaixe.