A Databricks publicou em 13 de maio de 2026 um post apresentando o Site Feasibility Workbench, um aplicativo open-source que roda inteiramente dentro do workspace da plataforma. O alvo é específico: ajudar equipes de pesquisa clínica a escolher onde abrir centros de estudo, combinando scoring por ML (machine learning, aprendizado de máquina) com Lakebase e o AI/BI Genie.
O problema da pesquisa clínica
Escolher onde abrir um centro de estudo clínico parece detalhe operacional, mas é uma das decisões mais caras de qualquer ensaio. Um centro mal escolhido recruta poucos pacientes, atrasa o cronograma, infla o orçamento e, na pior das hipóteses, compromete a estatística do estudo. Times de operações clínicas costumam decidir com base em planilhas e relacionamentos históricos com investigadores, mas o volume de variáveis hoje exige modelos mais formais.
Os três pilares técnicos
O Workbench se apoia em três componentes da própria Databricks. O primeiro é o scoring por ML, que avalia cada centro candidato em dimensões de elegibilidade, capacidade e desempenho passado. O segundo é o Lakebase, o Postgres gerenciado da Databricks, que guarda o estado operacional do app — rascunhos de análise, shortlists salvas, anotações de time. O terceiro é o AI/BI Genie, a interface de linguagem natural da plataforma que permite ao usuário fazer perguntas sobre os dados sem precisar escrever SQL.
Um score composto com quatro dimensões
O score final de cada centro é calculado a partir de quatro variáveis com pesos explícitos: RWE Patient Access (35%), que mede o acesso real a pacientes; Operational Performance (30%), que olha histórico operacional; Site Readiness e SSQ (20%), que avalia prontidão do centro e qualidade do start-up; e Protocol Execution (15%), que pesa execução de protocolos anteriores. Os pesos são explicitamente documentados, o que importa em contextos regulatórios onde uma decisão precisa ser auditável meses depois.
Tudo dentro do workspace
Um detalhe arquitetural relevante é que o Workbench não chama APIs externas. Mapas interativos, análise deep-dive e compartilhamento de listas com membros do time são gerados a partir dos dados que já vivem no lakehouse. Para a indústria de saúde, essa propriedade é menos estética e mais conformidade: dados de pesquisa clínica esbarram em regulações como HIPAA nos Estados Unidos e LGPD no Brasil, e qualquer chamada externa abre superfície de auditoria.
Lakebase como pedaço operacional
A novidade conceitual mais interessante para times de dados é o uso do Lakebase. Tradicionalmente, lakehouse é lugar de dado analítico — imutável, particionado, otimizado para leitura em larga escala. Estado operacional é lugar de OLTP (online transaction processing, processamento transacional online), com Postgres dedicado fora do data lake. Ao integrar um Postgres gerenciado dentro da Databricks, o Workbench mostra um padrão viável: dados analíticos no lakehouse, estado operacional do app no Lakebase, sem precisar montar pipelines de sincronização entre dois mundos.
Genie como interface natural
Outro ponto prático é a entrada do Genie como camada de pergunta-e-resposta. Em vez de exigir que o usuário clínico saiba escrever SQL para perguntar quantos centros na região sul atendem o critério X?, o Genie traduz a pergunta em consulta. Para times de dados que constroem produtos internos, isso significa que parte do tempo gasto criando dashboards customizados pode migrar para tunar bem o próprio Genie e deixar o usuário formular as perguntas que precisar.
O que devs e arquitetos podem tirar disso
Mesmo quem não trabalha com pesquisa clínica pode olhar o Workbench como template. Construir um Databricks App que combina scoring ML, Lakebase para estado operacional e Genie para queries naturais é um padrão repetível em muitas situações internas: ranqueamento de fornecedores, seleção de territórios para expansão, priorização de leads. O fato de ser open-source ainda permite fork e adaptação, sem partir do zero.
Pontos não cobertos no anúncio
O post não detalha qual modelo de ML está por trás do scoring nem como cliente atualiza os pesos das quatro dimensões para refletir o próprio domínio. Também não há menção pública a métricas de desempenho do app em produção real — quantos centros já foram avaliados, qual a precisão do score em estudos já concluídos.
Reportado originalmente por Databricks Blog em 2026-05-13.
