eQMS open source: existe e vale a pena?

O que existe em open source para qualidade GxP, por que "grátis" é mais caro em farma regulada, e quando — se em algum momento — OSS faz sentido.

Toda vez que sobe a discussão de custo de eQMS, alguém da TI sugere "e se a gente usar open source?". A pergunta merece resposta direta — e ela tem duas partes: o que existe em OSS pra qualidade GxP, e por que a economia desaparece quando você soma o que precisa em volta.

O que existe em OSS

Mapeando o que está disponível pra qualidade em geral:

• Document management: Nuxeo, Alfresco Community, OpenKM. Maduros em DMS genérico, sem features Part 11 nativas.
• BPM / workflow: Camunda Community, Bonita Community. Engines de workflow, exigem desenvolvimento extensivo pra virar QMS.
• Bug tracker reaproveitado: alguns times tentam usar Redmine/GitLab Issues como tracker de CAPA. Funciona até a inspeção.
• Suítes "QMS" OSS: existem alguns projetos pequenos (OpenLibrary, SimpleQMS), todos com base de usuários reduzida e atualização irregular.

Nada disso chega de fábrica com Part 11/RDC 658/Annex 11. São tijolos — não casas prontas.

O custo real da abordagem OSS pra eQMS

Construir eQMS validado em cima de OSS exige:

1. Desenvolvimento

Implementar audit trail tamper-evident, segregação de duties no domínio, assinatura Part 11 com significado, hash-chain, RBAC granular, two-person rule. Custo: 6-18 meses de equipe (2-3 devs + 1 arquiteto). R$ 600k-2M.

2. Validação como Cat 5

Software customizado pelo cliente vira Cat 5 do GAMP. Exige SDLC formal documentado, testes unitários, code review, change control rigoroso. Custo: R$ 200-500k em consultoria especializada + manutenção contínua.

3. Operação e segurança

Hardening, monitoramento, backup validado, gestão de vulnerabilidades, patch management. Em OSS isso é responsabilidade integral da empresa.

4. Sustentação a longo prazo

Quem mantém o código depois? E quando o dev que conhecia sai? Risco de "código órfão" é real e cresce com o tempo.

O que dá certo em OSS

Componentes de infraestrutura em OSS (Postgres, Linux, Nginx, Docker) são excelentes e usados pelo próprio Veeva/MasterControl/NOAH. Eles são Cat 1 do GAMP — qualificação de instalação, não validação de funcionalidade GxP.

O problema é o nível acima: a camada de regras de qualidade. Pra essa camada, OSS é matéria-prima, não solução.

Quando OSS realmente faz sentido

Em 3 cenários muito específicos:

1. Empresa de tecnologia médica com TI forte que precisa controle total do código e tem capacidade real de manter SDLC formal por anos
2. Acadêmico/pesquisa não-regulado mas que quer disciplina parecida com GxP
3. Componentes auxiliares que não tocam dados regulados (wiki interna, dashboard analítico, comunicação interna)

Pra farma média/pequena brasileira, OSS quase nunca faz sentido como base de eQMS regulado.

A pegadinha do "OSS validado"

Alguns fornecedores comercializam "distribuições" de OSS validadas. Tecnicamente são forks com customização. O custo de licença some, mas o custo de validação + sustentação volta — em montantes parecidos com SaaS validado tradicional. A economia desaparece, e fica o risco de fornecedor menor sem garantia de continuidade.

Comparação resumida pra médio porte BR

Caminho	Investimento ano 1	Risco
OSS customizado	R$ 1-3M	Alto (dependência interna)
OSS validado (distro)	R$ 300-800k	Médio (fornecedor menor)
eQMS validado de fábrica	R$ 150-300k	Baixo

O que muda com a categoria 4 (validado de fábrica)

Categoria 4 (NOAH) entrega: licença em reais por escopo + pacote IQ/OQ executado + Part 11/RDC 658 fora-da-caixa + sustentação no contrato. O ponto que OSS perde é exatamente esse: você não tem que construir nem manter.