Testes orientados a evidência para sistemas de pesquisa regulada

OpenFactory pode automatizar checagens limitadas de infraestrutura e aplicativo para organização de pesquisa por contrato. Não determina conformidade FDA, valida sistema computadorizado inteiro automaticamente, nem substitui sistema de qualidade e aprovações responsáveis da organização regulada.

21 CFR Part 11  aplica-se a registros e assinaturas eletrônicos especificados e inclui controles além de imagem de sistema operacional: validação de sistema, proteção e recuperação de registros, checagens de acesso e autoridade, trilhas de auditoria com timestamp, treinamento, políticas, controles de documentação e requisitos de assinatura. Regras predicate aplicáveis e uso pretendido devem ser estabelecidos por pessoal legal, regulatório e de qualidade qualificado.

A orientação atual Computer Software Assurance da FDA  descreve abordagem baseada em risco para software de produção e sistema de gestão de qualidade. Equipes devem determinar aplicabilidade ao sistema e contexto em vez de tratar contagem genérica de testes como validação.

O que evidência OpenFactory pode apoiar

• proveniência exata de receita e origem para build de imagem;
• asserções de pacote, serviço, arquivo, porta e comando em guest inicializado;
• evidência limitada de GUI e screenshot onde asserção suportada roda;
• timestamps, saída e identificadores de artefato por run;
• testes negativos e de recovery repetíveis; e
• comparação de artefato novo contra baseline aprovada.

Cada item é evidência para requisito declarado. Nenhum estabelece aceitabilidade regulatória sozinho.

Comece com uso pretendido e risco

Antes de autoria de testes, documente:

1. uso pretendido do sistema computadorizado;
2. registros e assinaturas regulados, se houver;
3. usuários, papéis, interfaces e fluxos de dados;
4. riscos a paciente, qualidade de produto e integridade de dados;
5. requisitos e critérios de aceitação ligados a esses riscos;
6. responsabilidades de fornecedor e componente; e
7. procedimentos de mudança, incidente, backup, recovery, retenção e descomissionamento.

Imagem de sistema operacional é só um item de configuração dentro desse sistema.

Exemplo de cenário limitado

Este exemplo checa serviço de integração sintético e configuração local de auditoria. Não alega que EDC, LIMS, banco de segurança ou workflow Part 11 está validado.

{
  "id": "synthetic-integration-smoke",
  "name": "Synthetic integration and audit smoke test",
  "enabled": true,
  "tests": ["boot", "login", "packages", "services"],
  "custom_tests": [
    {
      "description": "Confirm the synthetic receiver and audit controls are present.",
      "assertions": [
        {
          "type": "service_running",
          "description": "The synthetic receiver is running.",
          "params": {"service": "synthetic-receiver"}
        },
        {
          "type": "port_listening",
          "description": "The synthetic receiver listens on its lab port.",
          "params": {"port": 2575}
        },
        {
          "type": "service_running",
          "description": "The Linux audit daemon is running.",
          "params": {"service": "auditd"}
        },
        {
          "type": "file_contains",
          "description": "The approved synthetic data path has an audit watch.",
          "params": {
            "path": "/etc/audit/rules.d/research-system.rules",
            "content": "-w /var/lib/synthetic-study"
          }
        }
      ]
    }
  ]
}

Use só dados de teste sintéticos não sensíveis em sistemas compartilhados de build e screenshot. Screenshot pode expor identificadores de sujeito, credenciais, notificações ou conteúdo de desktop não relacionado. Defina controles de captura, redação, acesso, retenção, export e deleção antes de coletar.

Pacote de evidência

Para cada run de teste aprovado, preserve:

• identificadores de requisito e risco;
• protocolo de teste e resultado esperado;
• revisão de receita, commits de origem, inventário de dependências e digest de imagem;
• identidade de ambiente e dados de teste;
• saída bruta, screenshots onde justificado, timestamps e versão do runner;
• desvios, passos falhos, investigações e links de reteste;
• identidade do revisor, decisão e data; e
• rastreabilidade de requisito a evidência e decisão de release.

Não rotule log de eventos automatizado ou pasta de screenshots como trilha de auditoria Part 11. Controles de trilha Part 11 concernem ações em registros regulados, retenção, disponibilidade e integridade em todo sistema aplicável.

Workflow de mudança e regressão

1. Avalie impacto da mudança proposta.
2. Selecione testes com base em risco e requisitos afetados.
3. Construa artefato imutável novo; retenha artefato aprovado anterior.
4. Rode protocolo em ambiente controlado.
5. Revise falhas e desvios sem deletar evidência desfavorável.
6. Obtenha aprovações exigidas de qualidade, segurança, negócio e regulatório.
7. Implante por change control e verifique configuração de produção.
8. Monitore drift e execute caminho de recovery testado quando necessário.

OpenFactory pode encurtar coleta de evidência para passos que de fato automatiza. Organização regulada permanece responsável por validação de uso pretendido, controles procedurais, governança de dados e decisão final de release.