Análise preditiva de reinternação hospitalar com dados

Reinternação hospitalar não é falha de sorte, é sinal que os dados já mostravam#

Todo hospital convive com o mesmo incômodo: um paciente recebe alta, volta para casa e reaparece no pronto-socorro dias depois. A reinternação hospitalar em até 30 dias é um dos indicadores mais observados na gestão assistencial porque combina três dores ao mesmo tempo: desfecho ruim para o paciente, ocupação de leito que poderia atender outra pessoa e custo que raramente é reembolsado na mesma proporção. A boa notícia é que grande parte desse risco não é aleatória. Ela está registrada, hoje, no prontuário eletrônico do paciente, nas prescrições, nos exames e no histórico de passagens anteriores. O problema é que esse dado normalmente fica parado, disperso entre sistemas, e ninguém olha para ele no momento em que a decisão de alta acontece.

Análise preditiva serve exatamente para isso: transformar histórico em um escore de risco calculado antes da alta, para que a equipe assistencial decida com mais informação. Neste artigo eu explico, do ponto de vista de quem implementa BI e dados na Microsoft, como sair do PEP e chegar a um escore visível no Power BI, sem prometer milagre e sendo honesto sobre onde o modelo erra.

O dado que prevê reinternação já existe, mas mora em silos#

Antes de falar de modelo, é preciso falar de origem. O sinal preditivo de readmissão costuma estar espalhado por fontes que não conversam entre si. Um projeto sério de engenharia de dados começa mapeando essas fontes e o que cada uma entrega.

Fonte	Exemplos de variáveis úteis	Cuidado principal
PEP (prontuário eletrônico)	Diagnósticos (CID), evolução clínica, procedimentos	Texto livre exige tratamento e padronização
Prescrição e farmácia	Polifarmácia, medicamentos de alto risco, adesão	Nomes comerciais versus princípio ativo
Laboratório e exames	Resultados fora de faixa, função renal, hemoglobina	Unidades e faixas de referência variam por laboratório
Administrativo e faturamento	Tempo de internação, número de passagens no ano, convênio	Não confundir volume de cobrança com gravidade
Cadastro do paciente	Idade, endereço, suporte familiar declarado	Dado sensível sob a LGPD, Lei nº 13.709/2018

O ponto que costumo repetir para clientes: o modelo não inventa informação, ele só aprende o que os dados já contêm. Se a evolução clínica é preenchida pela metade, ou se cada unidade cadastra comorbidade de um jeito, o preditor herda esse ruído. Por isso a etapa menos glamourosa, a de padronizar e limpar, é a que mais decide o resultado final. Não existe atalho de ferramenta que compense base ruim.

Fatores de risco reais, não achismo#

A literatura clínica de readmissão é consolidada há anos, e alguns fatores aparecem de forma recorrente. Vale listar os que mais fazem diferença na prática, porque eles orientam quais dados priorizar na coleta.

• Número de internações anteriores no período recente. Histórico de passagens é um dos preditores mais fortes e mais fáceis de extrair.
• Comorbidades e polifarmácia. Pacientes com múltiplas condições crônicas e muitos medicamentos simultâneos concentram risco.
• Tempo de internação (LOS) fora do esperado para o diagnóstico, tanto muito curto quanto muito longo.
• Marcadores laboratoriais como função renal alterada, sódio e hemoglobina em faixas de atenção.
• Contexto social: suporte domiciliar, acesso a acompanhamento e capacidade de seguir a orientação de alta.

Repare que o último item é o mais difícil de capturar e, muitas vezes, o mais determinante. Um paciente clinicamente estável que mora sozinho e não tem quem administre a medicação pode ter risco maior do que outro aparentemente mais grave, porém com rede de apoio. Modelos que ignoram o contexto social tendem a acertar menos justamente nos casos em que a intervenção seria mais barata.

Onde treinar o modelo: Azure Machine Learning ou Microsoft Fabric#

Aqui a decisão é de arquitetura, não de moda. As duas opções são da Microsoft e convivem bem, mas resolvem necessidades diferentes.

O Azure Machine Learning é o ambiente mais completo para quem quer controle total do ciclo de vida do modelo: experimentação, versionamento, pipelines de treino, registro de modelo e publicação como endpoint. É a escolha natural quando o hospital tem, ou vai ter, um time de ciência de dados que precisa iterar em algoritmos, comparar métricas e reprocessar com frequência.

O Microsoft Fabric, anunciado pela Microsoft em 2023, unifica engenharia de dados, ciência de dados e BI sobre o OneLake. Ele traz notebooks e capacidade de treinar modelos junto do restante da plataforma analítica, o que reduz o vaivém de dados entre ambientes. Para quem já vai concentrar o BI hospitalar no Fabric, treinar e servir ali mesmo simplifica a operação. Se ainda tem dúvida sobre a plataforma, vale ler nosso guia sobre Microsoft Fabric.

Critério	Azure Machine Learning	Microsoft Fabric
Foco principal	Ciclo de vida de ML de ponta a ponta	Plataforma analítica unificada com ML integrado
Melhor quando	Há time dedicado de data science iterando muito	O BI já está no Fabric e se quer menos integração
Dado próximo do BI	Requer conectar ao Power BI/OneLake	Nativo no OneLake, alimenta o Power BI diretamente
Faturamento	Consumo de computação Azure	Capacity Units da capacidade Fabric (SKUs F2 a F2048)
Curva de operação	Maior, mais peças a gerenciar	Menor para quem já está no ecossistema

Uma observação técnica que costuma passar batido: independentemente de onde o modelo roda, o resultado que chega ao Power BI é, no fim, uma tabela com paciente e escore. O motor VertiPaq do Power BI comprime colunas por cardinalidade, então uma coluna de escore contínuo com muitas casas decimais infla o modelo sem ganho prático. Costumamos arredondar o escore e trabalhar com faixas, o que também facilita a leitura clínica. Boas práticas de modelagem valem aqui como em qualquer projeto, e vale revisar nosso material de modelagem e DAX.

O escore de risco só vale se aparecer na hora da decisão#

Modelo bom em notebook e invisível na enfermaria não muda desfecho. O objetivo do projeto é que o escore chegue ao profissional antes da alta, dentro do fluxo de trabalho, não em um relatório que ninguém abre. No Power BI isso costuma virar uma visão operacional por leito ou por paciente, com faixas de risco em vez de um número cru.

Faixa de escore	Leitura sugerida	Ação típica de alta
Baixo	Risco compatível com alta padrão	Orientação de alta usual e retorno de rotina
Médio	Atenção, revisar fatores modificáveis	Reforço de orientação, conciliação medicamentosa
Alto	Risco elevado de readmissão em 30 dias	Plano de alta reforçado, contato pós-alta agendado

As faixas acima são um exemplo de estrutura, não um corte oficial: cada instituição calibra os limites com sua própria realidade e validação clínica. O importante é que a divisão em faixas seja definida junto com a equipe assistencial, e não imposta pela área de dados.

Quando faz sentido agir e não só olhar, dá para acionar o Power Platform: um Power App simples para registrar a conduta tomada na alta de alto risco, ou um fluxo no Power Automate que notifica o time de continuidade do cuidado. O detalhe que separa projeto útil de dashboard bonito é o loop de feedback: registrar o que foi feito permite, meses depois, avaliar se a intervenção nos casos de alto risco realmente reduziu retorno.

Honestidade sobre o que a previsão não faz#

Esta seção é a que mais respeito, e a que mais falta em fornecedor apressado. Um escore de risco é uma probabilidade, não um oráculo.

Primeiro, todo modelo erra em duas direções. Ele aponta risco alto em paciente que não voltaria (falso positivo) e deixa passar paciente que voltará (falso negativo). Não existe ajuste que zere os dois ao mesmo tempo. Aumentar a sensibilidade para não perder caso grave gera mais alarmes, e alarme demais leva a equipe a ignorar o escore. Esse equilíbrio é uma decisão de gestão, não um botão técnico.

Segundo, correlação não é causa. O modelo pode aprender que certo convênio ou certa unidade se associa a mais retorno, quando o que está por trás é perfil socioeconômico ou registro incompleto. Agir cegamente sobre esses sinais pode ser injusto e ineficaz. Por isso o escore precisa ser interpretável: a equipe deve conseguir ver quais fatores mais pesaram, para julgar se fazem sentido clínico.

Terceiro, modelo envelhece. Mudou protocolo, trocou sistema, chegou uma nova epidemia sazonal, e a relação entre variáveis e desfecho muda. Isso é o chamado desvio de dados. Um preditor de readmissão não é entregável de fim de projeto, é ativo que precisa de monitoramento e reciclagem periódica, o que conversa com a lógica de sustentação de BI.

Por fim, dado de saúde é dado pessoal sensível sob a LGPD. Finalidade, base legal, controle de acesso e trilha de auditoria não são formalidade, são requisito. Tratamos governança como parte do projeto, não como anexo, e vale ver como pensamos governança e LGPD no Power BI.

Um caminho de implementação realista#

Para quem está começando, o pior erro é tentar o modelo perfeito no primeiro mês. O caminho que funciona é incremental.

1. Discovery e viabilidade de dados. Entender quais fontes existem, o estado de preenchimento do PEP e se há histórico suficiente para treinar. Sem isso, qualquer promessa de acurácia é chute.
2. Base padronizada. Consolidar PEP, prescrição, laboratório e administrativo em um modelo confiável. Aqui mora a maior parte do esforço.
3. Modelo inicial simples. Começar com um preditor interpretável e uma linha de base honesta, medindo contra o que já se faz hoje.
4. Escore no Power BI. Levar o resultado para a visão operacional, com faixas e explicabilidade.
5. Ação e medição. Fechar o loop com conduta registrada e avaliação de impacto ao longo do tempo.

Preços de plataforma variam bastante e devem ser confirmados na fonte oficial da Microsoft. De forma aproximada, licenças como Power BI Pro e Power BI Premium por Usuário (PPU) são cobradas por usuário e por mês, enquanto a capacidade Fabric é contratada por SKU (de F2 a F2048) com faturamento em Capacity Units. O dimensionamento certo depende de volume de dados e número de usuários, e faz parte de um bom discovery e assessment.

Perguntas frequentes#

Preciso de um time de ciência de dados para começar?

Não necessariamente para o primeiro passo. Um modelo inicial interpretável, apoiado por uma base bem organizada, já entrega valor e serve de linha de base. Um time dedicado passa a fazer diferença quando o hospital quer iterar com frequência, comparar algoritmos e manter o modelo em produção com rigor. O mais importante no início é a qualidade do dado, não a sofisticação do algoritmo.

Azure Machine Learning ou Microsoft Fabric, qual escolher?

Depende de onde está o seu BI e do seu apetite operacional. Se você já vai concentrar a analítica no Fabric, treinar e servir ali reduz integrações e leva o escore direto ao Power BI pelo OneLake. Se há um time de data science que precisa de controle total do ciclo de vida do modelo, o Azure Machine Learning é mais adequado. As duas são Microsoft e convivem bem, então a decisão é de arquitetura.

O modelo vai me dizer com certeza quem vai voltar?

Não, e desconfie de quem prometer isso. O escore é uma probabilidade, sujeita a falsos positivos e falsos negativos. Ele melhora a decisão de alta ao concentrar atenção nos casos de maior risco, mas não substitui o julgamento clínico. O valor está em priorizar, não em prever com certeza.

Como fica a LGPD nesse tipo de projeto?

Dado de saúde é dado pessoal sensível sob a Lei nº 13.709/2018. O projeto precisa de finalidade clara, base legal, controle de acesso por perfil, minimização de dados e trilha de auditoria. Tratamos isso como requisito de arquitetura desde o desenho, com governança aplicada às camadas de dados e aos relatórios, não como etapa final.

Quanto tempo até ver resultado?

O primeiro escore útil no Power BI costuma vir antes do modelo estar perfeito, porque a maior parte do esforço é organizar dados. O impacto real, redução de readmissão, só é mensurável depois de fechar o loop de ação e observar coortes ao longo de meses. Prometer redução de indicador em semanas é sinal de alerta.

Dá para reaproveitar isso para outros indicadores?

Sim. Uma vez que o PEP, a prescrição, o laboratório e o administrativo estão consolidados em uma base confiável, o mesmo alicerce serve para tempo de permanência, ocupação de leito, glosas e outros temas assistenciais e financeiros. O investimento pesado é na base de dados, e ele se paga em vários casos de uso.

Onde isso te leva#

Prever reinternação hospitalar não é sobre comprar uma ferramenta, é sobre organizar o dado que você já tem, treinar um modelo honesto e colocar o escore na frente de quem decide a alta. A parte técnica, Azure Machine Learning ou Fabric, escore no Power BI, ação no Power Platform, é resolvível. O que separa projeto que muda desfecho de dashboard esquecido é seriedade com o dado e com os limites da previsão.

Se você quer avaliar a viabilidade desse tipo de projeto na sua realidade, fale com a gente e a gente monta o caminho a partir do que você já tem.