O que é o eSource?

De acordo com a FDA, os dados de origem eletrónica (eSource) são definidos como «dados inicialmente registados em formato eletrónico. Podem incluir informações contidas em registos originais e cópias autenticadas de registos originais de resultados clínicos, observações ou outras atividades registadas antes ou durante um ensaio clínico, utilizadas para a reconstrução e avaliação do ensaio.»

O eSource já é amplamente utilizado em ensaios clínicos. Exemplos comuns de eSource incluem:

  • Resultados relatados pelo avaliador e pelo doente («avaliações eletrónicas de resultados clínicos», ou eCOA)
  • Dados provenientes de instrumentos clínicos, tais como equipamentos de imagiologia, aparelhos de ECG ou dispositivos vestíveis
  • Dados laboratoriais provenientes de um Sistema de Gestão de Informação Laboratorial (LIMS); ou
  • Formulários eletrónicos de consentimento informado (eICFs)

No entanto, os centros de investigação clínica não têm, historicamente, registado os seus dados de origem numa aplicação eletrónica financiada pelo patrocinador. Consequentemente, os patrocinadores não têm acesso direto aos dados de origem dos centros e, por isso, exigem que estes transcrevam os seus dados de origem para o sistema de Captura Eletrónica de Dados («EDC») do estudo, que aloja os Formulários Eletrónicos de Relatório de Caso («eCRFs»). Os eCRFs são conjuntos de dados distintos e inter-relacionados que, frequentemente, refletem os procedimentos dos centros. Exemplos típicos de eCRFs incluem dados demográficos, elegibilidade, sinais vitais, teste de gravidez na urina, exame físico, história clínica, medicação concomitante, eventos adversos, responsabilização do investigador principal e estado do participante.

Neste contexto – e para efeitos desta publicação no blogue – o termo «eSource» refere-se à utilização de um sistema eletrónico para recolher dados de origem no local.

Por que é que as instituições não utilizam o EHR como ferramenta de recolha de dados.

Os sistemas de registos de saúde eletrónicos (EHR) foram concebidos para os fluxos de trabalho dos cuidados de saúde, e não para os fluxos de trabalho dos ensaios clínicos. Consequentemente, a maioria dos centros não utiliza um sistema de registos de saúde eletrónicos (EHR) para recolher dados de origem específicos do estudo (consulte o nosso documento técnico, “Umacomparação entre dados de EMR e eSource). O maior obstáculo é que os modelos de EHR geralmente não são suficientemente flexíveis para acomodar as necessidades de um ensaio. Por exemplo, não existe o conceito de «Evento Adverso» num sistema de EHR – um «Evento Adverso» é um conceito específico do protocolo que é altamente contextual ao estudo.

O que a maioria dos locais faz é criar fichas de trabalho em papel utilizando o Microsoft Word ou outro programa de processamento de texto. Traduzem os requisitos do protocolo em fichas de trabalho, imprimem-nas no dia da visita e, em seguida, preenchem-nas à mão.

Qual é a dimensão da utilização do site eSource?

O eSource para centros de investigação é uma das categorias de software que mais cresce na investigação clínica. A CRIO é o principal fornecedor de eSource para centros de investigação e licencia o seu software diretamente aos centros. Atualmente, estimamos que 20% dos centros de investigação sediados nos EUA tenham adotado o eSource. A grande maioria desses centros utiliza o eSource da CRIO.

Esta adoção concentra-se especialmente nos centros de desempenho superior e mais profissionais, incluindo a classe emergente de redes de centros. Estas redes, muitas das quais apoiadas por investidores institucionais, estão a utilizar o eSource para melhorar a produtividade e aumentar a padronização (consulte o nosso livro branco, «A Reinvenção das Redes de Centros, Parte 2»). À medida que estas redes se expandirem, o mesmo acontecerá com a utilização do eSource.

Por exemplo, nos ensaios clínicos das vacinas contra a COVID-19 da Pfizer e da Moderna, que dependeram fortemente de redes de centros de ensaio, mais de 30% dos centros nos EUA são atualmente clientes da CRIO. Na maioria das indicações, existem centros eSource da CRIO suficientes para realizar um estudo na íntegra.

 

Então, se os centros de ensaio estão a recolher dados desta forma, por que precisamos de um EDC?

O eSource permite que os centros de investigação recolham dados no âmbito de um sistema de fluxos de trabalho específico do centro. No entanto, o eSource, por si só, não oferece os fluxos de trabalho de que os patrocinadores necessitam para rever, consultar e bloquear os dados antes da extração – funcionalidades que os sistemas de gestão de dados de ensaios clínicos (EDC) possuem.

A CRIO resolveu este problema com uma solução integrada eSource-EDC. Esta solução exclusiva tem três componentes:

Na prática, o Reviewer é o sistema de recolha eletrónica de dados (EDC) do ensaio clínico. Contudo, ao contrário do modelo tradicional, o centro não tem de voltar a introduzir os dados no EDC, e o promotor não tem de realizar a verificação dos dados na fonte relativamente a esses dados.

As vantagens do modelo CRIO integrado para o patrocinador devem ser evidentes:

  • Dados de melhor qualidade (uma vez que as verificações de edição são executadas durante a recolha de dados, e não posteriormente)
  • Acesso imediato aos dados do local; e
  • Custo mais baixo

Para uma explicação completa do nosso modelo, consulte o nosso guia introdutório «O modelo EDC atual, que já não funciona, vs. o modelo CRIO».

Por que é que o CRIO não pode enviar os dados do eSource para o fornecedor de EDC da minha escolha?

A nossa experiência mostra que esta é uma experiência insatisfatória para os patrocinadores. O modelo integrado da CRIO é superior a uma API de eSource para EDC de terceiros porque:

  1. Existe apenas UMA versão de estudo no modelo CRIO. Os modelos do eSource e do eCRF são idênticos. Se o CRIO eSource fosse integrado com outro sistema EDC, o patrocinador teria de criar dois modelos distintos e, em seguida, efetuar um mapeamento entre os dois. Trata-se de três tarefas distintas, e não de uma única.
  2. Pela nossa experiência, são muito poucos os sistemas EDC que dispõem de uma API robusta que permita uma integração perfeita. O custo de desenvolver e validar uma integração – recorrendo a recursos de engenharia – acaba provavelmente por ser equivalente ao custo de introduzir os dados manualmente.

E se eu quiser trabalhar com sites que ainda não utilizam o CRIO eSource?

Como regra geral, os centros são livres de utilizar o sistema eletrónico da sua escolha para recolher dados de origem, desde que o sistema esteja em conformidade com a norma 21CFR11. Assim, um patrocinador não determinaria normalmente como um centro deve recolher os seus dados de origem.

No entanto, um patrocinador pode exigir contratualmente que um centro utilize um sistema eSource específico como condição para participar no estudo. A experiência da CRIO indica que mais de 95 % dos centros optariam por utilizar o CRIO se isso fosse uma condição do estudo. Uma vez que o CRIO eSource foi concebido para os centros, o patrocinador tem a garantia de que os seus fluxos de trabalho serão intuitivos para os novos centros.

Então, por que é que os centros não podem simplesmente introduzir os dados no EDC?

A FDA indicou que a introdução direta de dados no EDC é permitida. Por exemplo, em orientações recentes orientação da FDA sobre DCT, a FDA indicou que certas atividades relacionadas com o ensaio podem ser realizadas por profissionais de saúde locais (HCPs): «Se os HCPs locais tiverem acesso ao eCRF, podem introduzir dados relacionados com o ensaio diretamente nos eCRFs» e «O pessoal do ensaio remoto ou os HCPs locais que submetem dados do ensaio diretamente no eCRF devem ser incluídos na lista de originadores de dados autorizados do promotor.»

No entanto, a maioria dos sistemas EDC apresenta limitações significativas que os impedem de serem sistemas de eSource eficazes a nível dos centros de ensaio. Tal como um sistema de eSource a nível dos centros de ensaio não consegue satisfazer as necessidades do promotor, um sistema EDC a nível do promotor não consegue satisfazer eficazmente as necessidades dos centros de ensaio.

Limitações do EDC

Eis algumas das limitações da maioria dos sistemas EDC:

  1. Não dispõem de fluxos de trabalho completos para um centro de ensaio. Aqui estão alguns exemplos de fluxos de trabalho do CRIO eSource, que são essenciais para a utilização e aceitação ideais do centro de ensaio:
    • Capacidade de armazenar informações de saúde protegidas (PHI) ao nível do paciente, para que as unidades saibam com quem estão a lidar e como contactá-los;
    • Possibilidade de agendar visitas num calendário unificado do local, com cálculos de intervalos de tempo integrados, e possibilidade de programar lembretes de consultas específicos para o local;
    • Capacidade de colaborar internamente em equipa através de mensagens internas e da atribuição de tarefas relacionadas com o estudo.
  2. Não dispõem de funcionalidades que permitam a recolha de dados em tempo real de forma compatível com os fluxos de trabalho do local.
    • Por exemplo, a maioria dos sistemas EDC armazena registos dinâmicos, como Conmeds ou AE, fora das visitas, embora a revisão e atualização desses registos faça normalmente parte da visita. O CRIO é diferente. A plataforma obtém a versão atual do registo em cada visita. Em seguida, solicita ao centro que confirme se houve alterações. Ao apresentar a versão atual dos registos durante a visita, o CRIO garante uma revisão consistente e precisa.
  3. Não conferem aos sites um controlo direto e permanente sobre os seus dados de origem.
    • Num sistema unitário de entrada direta do EDC, o patrocinador detém o controlo final sobre a origem dos dados dos centros. Muitos centros – e algumas entidades reguladoras na Europa – manifestaram a sua preocupação com a falta de controlo direto do investigador principal sobre os registos de origem.

Assim, embora a introdução direta de dados no EDC seja permitida pelas orientações da FDA, os casos de utilização mais realistas dizem respeito a aplicações específicas, como a recolha de conjuntos de dados limitados por parte de um profissional de saúde ou de um avaliador centralizado. Raramente é escalável para os centros de investigação clínica, que apresentam fluxos de trabalho e requisitos de utilizador complexos.

Em que difere o modelo eSource de um modelo EDC?

Tal como um modelo EDC, o modelo eSource deve conter os dados necessários para sustentar a análise estatística e as Tabelas, Listas e Figuras («TLF»).

Ao contrário de um modelo de EDC, o modelo de eSource deve ser uma ferramenta de fluxo de trabalho destinada aos centros para promover o cumprimento do protocolo. Assim, os formulários devem conter instruções completas e detalhadas, bem como perguntas mais específicas que induzam e documentem a conformidade do centro com o protocolo.

Por exemplo, um eCRF para sinais vitais necessita, na verdade, apenas de três pontos de dados para efeitos de análise estatística:

  1. Data e hora do procedimento
  2. Sistólica
  3. Diastólica

No entanto, a versão eSource deve conter dados que comprovem o cumprimento da metodologia especificada no protocolo: por exemplo, a posição do paciente, o tempo que o paciente permaneceu nessa posição, o braço utilizado e/ou o manguito de pressão arterial utilizado.

A elaboração de modelos eSource é uma competência específica. Na CRIO, concebemos os modelos como um serviço. Utilizamos o protocolo como guia, elaborando o modelo de forma a garantir a conformidade. Em seguida, utilizamos um marcador «Core» para designar o subconjunto de campos exigidos para o TLF. O marcador «Core» é útil para que o patrocinador realize um acompanhamento baseado no risco. Permite-lhe concentrar-se nos pontos de dados mais críticos que irão influenciar a análise.

Adoraríamos mostrar-lhe como funciona. Para saber mais sobre a nossa solução integrada eSource-EDC, marque uma demonstração aqui.

 

Voltar ao blogue

Dê aos locais o que eles precisam e veja o seu estudo ser bem-sucedido.

Agende uma demonstração