Ir para o conteúdo principal
Setores

A inteligência de operações clínicas pertence ao Lakehouse

Como Databricks Apps, Lakebase e AI/BI Genie eliminam a pilha de integração entre dados clínicos e aplicativos de suporte à decisão — e por que essa mudança de arquitetura é o que as operações clínicas estavam perdendo.

por Nicholas Siebenlist

  • O que é: O Site Feasibility Workbench é um aplicativo Databricks de código aberto que executa a seleção de locais de ensaios clínicos inteiramente dentro do workspace Databricks — combinando pontuação de locais impulsionada por ML, Lakebase para estado operacional e AI/BI Genie para acesso a dados em linguagem natural, sem chamadas de API externas ou pipelines de sincronização.
  • O desafio que resolve: 37% dos locais de investigação não atingem as metas de recrutamento, e a causa raiz é arquitetural — dados de operações clínicas e os aplicativos que os utilizam residem em sistemas desconectados, forçando decisões em planilhas e criando sobrecarga de integração, proliferação de credenciais e atraso de sincronização que corrói a confiança nos dados.
  • Resultados e desfechos: Modelos LightGBM segmentados por TA treinados no seu próprio histórico de CTMS, EDC e IRT — não em médias da indústria — produzem pontuações que melhoram à medida que seu portfólio cresce, com explicações impulsionadas por SHAP armazenadas como tabelas Delta governadas e versionadas. Cada previsão carrega atribuição impulsionada por SHAP armazenada como uma tabela Delta governada, tornando a lógica do modelo tão auditável e versionada quanto a própria pontuação.

O problema dos dados clínicos não é um problema de armazenamento. A maioria das organizações já possui um data warehouse, um CTMS, um EDC e, em algum lugar a jusante, uma camada de BI. O problema é que nenhum desses sistemas se comunica de forma a suportar as decisões reais que as equipes clínicas precisam tomar — e, portanto, as decisões são tomadas em planilhas.

Hoje, estamos lançando o Site Feasibility Workbench como um Databricks App totalmente open-source — para mostrar como é a inteligência de operações clínicas quando a aplicação, os modelos e os dados residem na mesma plataforma. O Tufts Center for the Study of Drug Development documentou que 37% dos sites de investigadores ativados matricularam menos pacientes do que suas metas, e um adicional de 11% não matriculou nenhum paciente — o efeito combinado sendo que 53% dos ensaios excederam seus cronogramas de recrutamento planejados, com um em cada seis levando mais do que o dobro do tempo planejado (Lamberti et al.; relatórios de impacto subsequentes do CSDD continuam a rastrear o baixo desempenho em níveis semelhantes). Até US$ 500.000 por dia em vendas de medicamentos não realizadas e US$ 40.000 por dia em custos diretos do ensaio, o baixo desempenho crônico do site é um dos impulsionadores de custo mais consequentes no desenvolvimento de medicamentos. Essa taxa combinada de baixo desempenho permaneceu essencialmente estável por pelo menos duas décadas. As ferramentas não são o problema. A arquitetura é.

As equipes de operações clínicas não precisam de mais dashboards conectados aos sistemas existentes. Elas precisam que suas aplicações de suporte à decisão residam onde seus dados e modelos residem — para que o ciclo de feedback entre uma previsão e o resultado operacional que a valida realmente se feche.

O Argumento da Arquitetura

A abordagem convencional para suporte à decisão clínica se parece com isto: dados analíticos residem em um data warehouse ou Lakehouse. Um banco de dados de aplicação separado contém o estado operacional. Um pipeline os mantém vagamente sincronizados. Uma aplicação web fica na frente de ambos, adicionando harmonização semântica na camada Silver. Cada camada introduz sobrecarga de integração, área de superfície de credenciais e um atraso de sincronização que corrói a confiança nos dados que a aplicação mostra.

Databricks Apps, Lakebase e AI/BI Genie eliminam cada uma dessas camadas — não abstraindo-as, mas tornando-as desnecessárias.

Databricks Apps executam a aplicação web dentro do workspace. O aplicativo autentica como um principal de serviço de workspace de primeira classe, consulta o Unity Catalog via SQL Statement API e chama o AI/BI Genie pela API REST do workspace — tudo em conexões internas. Os dados de operações clínicas nunca cruzam um limite de workspace. O aplicativo herda os controles de acesso do Unity Catalog sem nenhuma configuração adicional.

Lakebase é a camada de banco de dados operacional — PostgreSQL gerenciado que escala para zero quando ocioso, provisionado e credenciado inteiramente dentro do sistema de identidade do workspace. Onde uma aplicação tradicional exigiria uma instância RDS gerenciada separadamente com seu próprio esquema, trabalhos de sincronização e rotação de credenciais, Lakebase está na mesma plataforma onde os dados e modelos residem.

AI/BI Genie fecha a última lacuna: acesso em linguagem natural a dados governados, incorporado diretamente no fluxo de trabalho da aplicação. Gerentes de estudo fazem perguntas em inglês simples contra as mesmas tabelas do Unity Catalog em que os modelos de ML foram treinados, com os mesmos controles de acesso aplicados.

O resultado é uma aplicação de operações clínicas que não faz chamadas de API externas, não mantém infraestrutura de banco de dados operacional separada e não requer pipeline de sincronização entre as camadas analítica e operacional.

Databricks Lakehouse Platform Figure 1
Figura 1 — A Databricks Lakehouse Platform como uma pilha unificada de inteligência clínica. Fontes externas ingerem via Lakeflow (Bronze → Silver → Gold). Mosaic AI treina modelos de IA/ML e grava previsões versionadas de volta no Unity Catalog. SQL Warehouse, Lakebase e AI/BI Genie servem o Databricks App — que é executado dentro do limite da plataforma com todas as conexões internas.

O Argumento da Auditabilidade

A abordagem padrão da indústria para viabilidade de sites depende de produtos de pontuação comerciais de fornecedores ou plataformas de análise fornecidas por CROs. Essas ferramentas são construídas sobre dados agregados da indústria — úteis como linha de base, mas cegas aos detalhes do seu portfólio. Um patrocinador com uma década de histórico de CTMS, EDC e IRT carrega sinais significativos sobre como seus sites se desempenham em seus protocolos.

Quando a pilha de ML reside no Databricks, esse conhecimento institucional se torna os dados de treinamento. Os modelos neste workbench são treinados em suas taxas de recrutamento históricas, seu histórico de qualificação de sites, seus padrões de falha de triagem e seu registro de execução de protocolo — não em médias da indústria. CMS Open Payments adiciona uma camada de sinal público que, quando usada apropriadamente, se correlaciona com o engajamento e a infraestrutura de pesquisa e está disponível gratuitamente. À medida que o portfólio de ensaios cresce, os modelos melhoram na mesma infraestrutura. Esse é o retorno composto que uma arquitetura de plataforma única permite e que um produto de pontuação licenciado não pode: cada novo estudo torna a previsão melhor, e cada novo relacionamento com o site é refletido na próxima execução de treinamento. MLflow rastreia cada execução de treinamento de modelo, parâmetros, métricas e artefatos — permitindo a comparação entre versões de modelo, reprodutibilidade sob demanda e uma trilha de auditoria completa, desde registros brutos de CTMS e EDC até a previsão implantada.

A dimensão regulatória também é importante aqui. 21 CFR Part 11, ICH E6(R3) e a orientação de Boas Práticas de Machine Learning (GMLP) da FDA, juntamente com a crescente ênfase da FDA na transparência no suporte à decisão algorítmica, tornam a explicabilidade do modelo e a governança de dados considerações materiais, não recursos opcionais. Como cada previsão carrega uma atribuição SHAP armazenada como uma tabela Delta governada do Unity Catalog — versionada em MLflow, com linhagem através do Unity Catalog, consultável — a lógica por trás da seleção de um site é tão auditável quanto a própria pontuação. Uma equipe de assuntos clínicos pode responder a uma pergunta de um comitê de monitoramento de dados com uma consulta SQL, não com um relatório de fornecedor de caixa preta.

O Que Construímos

O Site Feasibility Workbench é um fluxo de trabalho guiado de seis etapas para a seleção de sites de ensaios clínicos: seleção de protocolo, restrições de pontuação, visão geral geográfica, classificação de sites, análise aprofundada de sites baseada em SHAP e lista restrita final. Considerações de diversidade são uma dimensão de pontuação de primeira classe, alinhadas com as expectativas do Plano de Ação de Diversidade da FDA sob a FDORA 2022.

Pontuações de viabilidade compostas combinam evidências do mundo real, dados de acesso a pacientes, desempenho histórico de sites, histórico de qualificação de sites, sinal KOL Open Payments e fatores de execução de protocolo — tudo impulsionado por modelos LightGBM segmentados por TA treinados no histórico de CTMS, EDC e IRT da própria organização.

A parte que vale a pena enfatizar não são as etapas do fluxo de trabalho ou os recursos do modelo. Dados em nível de paciente herdam os controles de acesso do Unity Catalog e o tratamento de PHI segue a postura de HIPAA Safe Harbor / Determinação de Especialista do patrocinador configurada no nível do catálogo ou esquema.

É o que a arquitetura possibilita: cada previsão carrega uma explicação SHAP armazenada como uma tabela Delta governada ao lado da própria previsão, tornando a lógica do modelo tão auditável e versionada quanto a pontuação que ela explica. Como cada previsão é decomposta em atribuições SHAP governadas, os patrocinadores podem auditar recomendações de subponderação sistemática de sites comunitários, instituições que atendem minorias ou investigadores de primeira viagem — transformando a explicabilidade em um controle de justiça.

Listas restritas salvas persistem no Lakebase para compartilhamento em equipe. O assistente AI/BI Genie responde a perguntas interdomínio contra as mesmas tabelas do Unity Catalog em linguagem natural. Nada disso requer infraestrutura fora do workspace.

Esta é uma camada de suporte à decisão, não um sistema de registro. O CTMS/EDC/IRT permanecem autoritativos. O workbench produz previsões cuja linhagem é governada no Unity Catalog e MLflow.

Clinical Trial Site Feasibility Workbench Figure 2
Figura 2 — Site Feasibility Workbench - Uma aplicação de fluxo de trabalho com estado para viabilidade de site leva à criação e compartilhamento de listas restritas de seleção de site baseadas em dados, aproveitando RWD & AI.

A aplicação completa — backend FastAPI, frontend React, notebooks seed e scripts de deploy — é publicada como um repositório open-source. A implantação em um workspace Databricks existente com Unity Catalog leva aproximadamente 30 minutos de tempo técnico de implantação, antes da revisão de segurança e validação específicas do patrocinador.

Um Módulo de uma Plataforma Maior

O Site Feasibility Workbench é a primeira versão pública de uma arquitetura mais ampla — o Databricks Clinical Operations Intelligence Hub — cobrindo todo o ciclo de vida do ensaio:

  • Viabilidade e Seleção de Sítio — o que este repositório cobre
  • Coorte de Pacientes e Recrutamento — construção de coortes alinhadas ao protocolo a partir de EHR e evidências do mundo real na escala do Lakehouse
  • Otimizador de Velocidade de Inscrição — previsão de gargalos de ML por sítio por mês com um horizonte de previsão de 1 a 3 meses
  • Monitoramento e Conformidade Baseados em Risco — monitoramento contínuo de anomalias de inscrição, atrasos de dados e desvios de protocolo

Todos os quatro são implantados como Databricks Apps. Todos os quatro consultam o Unity Catalog diretamente. Nenhum faz chamadas de API externas. Quando os aplicativos clínicos residem onde seus dados e modelos residem, o ciclo de feedback se fecha. Modelos de seleção de sítio aprendem com os resultados de inscrição. Pontuações de risco são atualizadas à medida que o histórico de emendas cresce. Cada recomendação impulsionada por IA carrega uma trilha de linhagem de volta aos registros do CTMS, EDC e IRT que a produziram.

Comece Agora

Clone o repositório público. Implante. Diga-nos o que você muda.

Repositório GitHub

Para o Clinical Operations Intelligence Hub completo — assista à gravação do BrickTalk: Scaling BioPharma Intelligence + Databricks Agentic Clinical Ops.

Lakebase e Databricks Apps em produção cobrem os primitivos da plataforma em profundidade.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original

Receba os posts mais recentes na sua caixa de entrada

Assine nosso blog e receba os posts mais recentes diretamente na sua caixa de entrada.