O Grupo Médico Atlántico coordena atividade clínica, faturamento, laboratório, pessoal e experiência do paciente em cinco sistemas que nunca conversaram entre si. Foi isso que construímos sobre o Microsoft Fabric — com qualidade de dado verificada em cada camada, antes que qualquer informação chegue a um único dashboard.
O Grupo Médico Atlántico opera uma rede de centros com atividade clínica, faturamento para seguradoras/convênios, laboratório próprio e equipe assistencial — cada área resolvida ao longo dos anos por um sistema diferente, sem uma camada de validação comum entre eles. Na saúde, um dado mal sincronizado não é só um relatório errado: é uma decisão clínica ou administrativa tomada com base em informação incompleta.
Barra proporcional ao volume de registros por sistema de origem. O HIS concentra mais da metade do total — o primeiro dado que definiu o desenho das dimensões e a ordem de carga na Bronze.
O que pediam não era mais um dashboard bonito. Era poder confiar no dado antes mesmo de olhar para ele: que, se um centro, uma especialidade ou um pagador mudasse, o número na tela refletisse isso de verdade — não uma carga incompleta ou um cache desatualizado que diz "correto" sem ter movido uma única linha.
O mesmo percurso que seguimos com qualquer cliente deste porte, adaptado a um setor onde o erro de dado tem custo real: primeiro um modelo que sustenta o negócio, depois uma arquitetura que valida antes de confiar, e por fim uma verificação que não se contenta com o pipeline dizendo "correto".
Desenhamos um esquema estrela com seis dimensões (centro, especialidade, pagador, paciente, pessoal, data) e cinco tabelas de fatos, cada uma com seu tipo de carga conforme a forma como o dado real muda: catálogos estáveis em SCD0, atributos que evoluem em SCD1, histórico de paciente-pagador em SCD2.
6 dimensões · 5 fatos · SCD0 / SCD1 / SCD2Arquitetura medallion (Bronze → Silver → Gold) sobre o Fabric. Antes que qualquer dimensão ou fato chegue ao Warehouse Gold, ele passa por um Gate de qualidade com Great Expectations que verifica nulos, faixas de valores, duplicados e relacionamentos — nada é disponibilizado sem passar por esse controle.
Great Expectations · Gate 3 em cada dimensão e fatoDescobrimos que o endpoint SQL do Fabric pode ficar dessincronizado após uma escrita do Spark: o Stored Procedure reporta "Succeeded" mesmo tendo processado zero linhas. Corrigimos isso com uma atualização de metadados via API do Fabric, com nova tentativa controlada — não com uma espera fixa que só mascara o sintoma.
Correção via API do Fabric · 0 falsos positivos em produçãoCinco dashboards em produção, um por área operacional, todos lendo de um Warehouse Gold que já passou pelo seu próprio controle de qualidade. Capturas reais da plataforma em produção — clique para ampliar.
Em cumprimento às nossas políticas de segurança da informação e aos compromissos de confidencialidade assumidos com o cliente — particularmente sensíveis no setor de saúde — o nome da organização, assim como os dados e bases de dados exibidos neste caso, foram modificados e anonimizados. A natureza e a magnitude dos resultados refletem fielmente o trabalho realizado.
Consultas por profissional, centro e dia da semana, com ocupação e no-show monitorados frente a uma meta.
Captura real · clique para ampliarReceita por seguradora/convênio e mix particular vs. convênio, com histórico SCD2 e valor pendente cruzado por centro.
Captura real · clique para ampliarTempo de resposta e % fora do SLA por tipo de exame e centro — o limite de referência (24h) ainda está pendente de confirmação com o cliente.
Captura real · clique para ampliarSegmentação de pacientes por fidelização, com tendência de interações e taxa de recorrência rastreadas a partir de um cadastro mestre único.
Captura real · clique para ampliarCobertura de turnos e horas trabalhadas por centro e função profissional, com a taxa de absenteísmo à vista para detectar lacunas a tempo.
Captura real · clique para ampliarA diferença entre um relatório e uma plataforma de dados auditável: a segunda mostra onde o próprio pipeline pode falhar antes que ele falhe em silêncio.
O endpoint SQL do Fabric pode ficar dessincronizado após uma escrita do Spark: o Stored Procedure reporta "Succeeded" mesmo tendo processado zero linhas. Detectado e corrigido com uma atualização de metadados via API antes de tocar a produção.
Uma sessão de notebook interativa continua consumindo capacidade por até 20 minutos após o último uso — invisível no pipeline, mas suficiente para esgotar uma capacidade de teste compartilhada.
O Gate 3 de qualidade (Great Expectations) valida 6 dimensões e 5 fatos antes que um único registro chegue ao Warehouse Gold — zero exceções silenciosas, zero "depois a gente ajeita".
Nenhum dashboard lê diretamente de um sistema de origem. Cada um consulta um modelo Gold que já passou pelo seu próprio controle de qualidade — a diferença não aparece na tela, aparece no fato de o número não mudar se você perguntar de novo.
fact_activity + dim_center + dim_specialty + dim_date, com SCD1 em centros e especialidades.
fact_billing + dim_payer + dim_patient, com SCD2 para o histórico de pagador por paciente.
fact_lab + dim_specialty + dim_date, com acompanhamento dos tempos de resposta por especialidade.
fact_patient_interaction + dim_patient, com rastreabilidade completa de 56.650 pacientes.
fact_staff_shift + dim_staff + dim_center, com validação de turnos por centro.
Nenhum número desta seção é uma promessa contratual. São os próximos passos já planejados sobre a arquitetura que já está em produção, não uma lista de desejos.
| Alavanca | Por que se aplica | Estimativa |
|---|---|---|
| Pipeline mestre orquestrado | Hoje Bronze, Silver e Gold são executados separadamente; o próximo passo encadeia as três camadas mais a atualização do Power BI em um único pipeline programado. | Diário · 23:00 |
| Generalizar a correção de sincronização | A atualização de metadados via API já aplicada ao Gold é estendida a qualquer tabela nova que dependa do endpoint SQL. | 0 falsos positivos |
| Autoscale do Spark | Evita superdimensionar a capacidade de teste nas cargas noturnas, agora que o padrão de uso real já é conhecido. | 5–15% de computação |
| Alertas ativos sobre o Gate 3 | Hoje o resultado do Gate é conferido no notebook; o próximo salto é notificar automaticamente quando uma carga não passar. | Detecção em minutos |
O pipeline mestre e sua validação programada (23:00 diária) são o próximo passo confirmado, não uma promessa fechada — são implementados sobre uma arquitetura que já roda em produção com dados reais, não do zero.
Se você tem atividade, faturamento ou pessoal espalhados em mais sistemas do que consegue contar de memória, provavelmente reconhece esse ponto de partida. Vamos conversar sobre o que o seu caso precisaria — começando, como no Grupo Médico Atlántico, por saber se você pode confiar no dado antes de construir um único dashboard.
Fale conosco →