Analytics global sem copiar dados de saúde para uma região central

cmsapointoo·16 de agosto de 2026·9 min de leitura

Uma visão global de desempenho não exige, por padrão, copiar eventos de saúde de todos os tenants para um único data warehouse. Uma arquitetura mais contida calcula métricas na região de origem de cada tenant e envia ao plano global somente um contrato mínimo de resultados, com dimensões limitadas e sem texto clínico. Essa é uma recomendação editorial de arquitetura, não uma exigência universal de HIPAA, LGPD ou Google Cloud.

O desenho ainda precisa de análise jurídica e técnica. Um total agregado não é automaticamente anônimo. Além disso, consultas multirregionais podem movimentar dados. Na documentação atual de preview, o BigQuery Global Queries executa subconsultas remotas e copia os dados remotos para tabelas temporárias na região primária, onde ficam por 24 horas. A palavra “global” não deve ser lida como “sem transferência”.

Separe eventos operacionais de métricas globais

Operação local e gestão global costumam ser tratadas como uma necessidade só. A primeira pode exigir eventos por agendamento, estado, horário e unidade. A segunda talvez precise apenas de contagens, taxas e tendências. Se o painel global não usa registros individuais, copiá-los amplia acesso sem acrescentar valor.

Em um modelo contido, cada tenant mantém eventos detalhados na região aprovada para sua operação. Um job local transforma esses eventos em um esquema pequeno, por exemplo: período, tenant, unidade autorizada, identificador de métrica, numerador, denominador, versão da regra e estado de qualidade. O repositório global recebe somente essas linhas calculadas. Texto livre, motivo clínico, especialidade rara e identificadores diretos ficam fora desse contrato.

Essa fronteira deve ser verificável. Use uma lista positiva de campos, validação de tipos e rejeição de colunas desconhecidas. Versione a definição de cada métrica para não comparar regras diferentes sob o mesmo nome. Para resultados de agenda, a taxonomia de resultados de agendamento mostra como limitar estados antes de alimentar relatórios.

Agregado não significa automaticamente anônimo

Em HIPAA, 45 CFR 164.514 prevê dois caminhos para determinar que health information não identifica um indivíduo: determinação por pessoa com conhecimento e experiência apropriados, com risco muito pequeno documentado, ou remoção dos identificadores enumerados no método Safe Harbor, desde que não haja conhecimento de que a informação restante possa identificar a pessoa. Somar registros não cria um terceiro caminho automático.

Uma célula com poucos casos, combinada com unidade, data e condição rara, pode permitir inferência mesmo sem nome. O risco depende do contexto, dos dados auxiliares disponíveis e de quem recebe o relatório. Não invente um tamanho universal de célula. Documente o método adotado e valide se dimensões, filtros e exportações preservam a conclusão.

A LGPD também exige cuidado. O artigo 12 trata dados anonimizados como fora do regime de dados pessoais, salvo quando a anonimização puder ser revertida com meios próprios ou esforços razoáveis, considerando fatores objetivos como custo, tempo e tecnologia disponível. Logo, “agregado” descreve uma transformação; não prova, sozinho, anonimização irreversível ou razoavelmente resistente.

Se a equipe não concluiu e documentou anonimização ou desidentificação aplicável, trate a métrica como dado potencialmente pessoal. Isso significa aplicar controle de acesso, finalidade, retenção, segurança e avaliação de transferência. É uma postura editorial conservadora para implementação, não uma conclusão de que toda métrica agregada identifica alguém.

O que o BigQuery Global Queries faz hoje

A documentação atual descreve Global Queries como recurso de preview, sujeito a termos de oferta pré-GA. O fluxo usa uma consulta na região primária, executa subconsultas nas regiões remotas e copia os resultados remotos para tabelas temporárias na região primária. Essas tabelas permanecem por 24 horas. A consulta final é executada na região primária usando as cópias temporárias.

Pushdowns podem reduzir a quantidade copiada, pois filtros e agregações compatíveis rodam perto da origem. Ainda assim, a própria documentação alerta que o volume transferido pode ser grande e recomenda testar com subconjunto pequeno. Um plano não deve depender da suposição de que o otimizador sempre enviará apenas o resultado mínimo. Confirme o plano, os jobs remotos, bytes processados, região primária e tabelas temporárias em um teste representativo.

A configuração regional enable_global_queries_execution controla se o projeto pode executar consultas globais naquela região. A configuração enable_global_queries_data_access controla se consultas globais podem copiar dados da região do projeto que os contém. Essas opções do BigQuery são distintas das constraints do Organization Policy discutidas abaixo. O recurso também tem limitações atuais, incluindo incompatibilidade com endpoints regionais e Assured Workloads. Texto da consulta pode aparecer no histórico dos jobs remotos. Antes de adotar o preview, compare essas propriedades com obrigações contratuais e requisitos de acesso.

Se a regra é “nenhum dado derivado sai da região”, Global Queries não atende essa regra apenas por ter execução distribuída. Se a regra permite transferência de um conjunto mínimo para região primária, o recurso ainda precisa de aprovação explícita quanto ao conteúdo, destino e retenção temporária. Essa conclusão decorre do comportamento documentado do produto, não de uma interpretação ampla da palavra “global”.

Política de localização não é garantia completa de residência

O Organization Policy Service oferece constraints de localização para limitar onde recursos compatíveis podem ser criados. A documentação do Google Cloud ressalta limites importantes: a política vale para recursos com atributo de localização suportado, não é retroativa para recursos existentes e não restringe recursos globais ou tipos não suportados.

Também há uma distinção entre localização do recurso e local de armazenamento ou processamento. Alguns serviços podem armazenar ou processar dados em local diferente da localização do recurso. A documentação diz que organization policies não são, por si, compromissos de armazenamento de dados. Portanto, uma constraint aprovada é uma camada de prevenção, não a prova inteira da residência.

O controle precisa combinar política de organização, configuração do dataset, localização do job, contrato do serviço, documentação do produto e teste de execução. Revise recursos existentes separadamente, porque a aplicação de nova política não os move. Para sistemas que atravessam UE e Brasil, consulte também a análise de adequação entre regiões e regimes.

Arquitetura editorial para métricas mínimas

Uma implementação de referência pode ter quatro estágios. Eles são uma proposta de engenharia para reduzir movimento e exposição, não uma receita jurídica universal:

Zona operacional local: recebe eventos detalhados, com acesso limitado ao tenant e retenção definida pela finalidade.
Transformação local: calcula métricas aprovadas e rejeita dimensões, texto e identificadores fora da lista positiva.
Gate de publicação: avalia qualidade, risco de células pequenas, versão da métrica e destino permitido.
Plano global: armazena apenas linhas publicáveis, com acesso separado, trilha de versão e prazo de retenção próprio.

O identificador do tenant pode continuar sendo dado confidencial, mesmo quando não identifica paciente. Não use nome de clínica em arquivos públicos ou dashboards sem necessidade. Para comparações, avalie se a audiência precisa ver cada tenant ou apenas uma coorte. Mantenha totais que permitam calcular taxas, mas evite dimensões tão granulares que recriem o evento original.

Em métricas de comparecimento, por exemplo, numerador e denominador por período podem bastar. O artigo sobre medição da taxa de comparecimento sem detalhes da consulta apresenta uma forma de separar resultado operacional de conteúdo clínico.

Controles que tornam a fronteira testável

Esquema allowlist: falhar quando aparecer campo não declarado, em vez de propagá-lo.
Região explícita: definir e registrar localização de datasets e jobs, sem depender de padrão implícito.
Identidade separada: conta local lê eventos; conta publicadora escreve somente métricas aprovadas.
Sem texto livre: impedir observações, URLs completas, termos de busca e campos clínicos no payload global.
Teste de inferência: revisar filtros, combinações e exportações que possam isolar indivíduos.
Retenção por camada: definir prazos distintos para eventos locais, staging, cópias temporárias e métricas globais.
Observabilidade sem conteúdo: registrar versão, contagem e erro, evitando reproduzir dados sensíveis em logs.

Inclua um teste negativo: tente publicar coluna clínica, identificador direto e dimensão não aprovada. O pipeline deve recusar. Inclua também um teste de localização que consulte metadados dos jobs e confirme onde houve execução ou cópia. Prints de configuração não substituem evidência do fluxo real.

Decisão por fluxo, não por slogan de arquitetura

“Data mesh”, “federado” e “global” não definem o resultado jurídico. Registre fonte, transformação, hipótese de anonimização, região de cálculo, conteúdo transferido, destino, retenção, audiência e possibilidade de drill-down. Se o painel volta ao evento individual, não é apenas uma camada agregada.

Também separe analytics interno de uso publicitário. Um campo permitido no warehouse não é automaticamente elegível para upload em mídia. A distinção entre base legal e política de Customer Match ajuda a manter essas decisões independentes.

Perguntas frequentes

Uma contagem por clínica já é anônima?

Não automaticamente. O risco depende da granularidade, das combinações possíveis, da audiência e dos dados auxiliares. Aplique o método jurídico e técnico pertinente e documente a conclusão.

Global Queries mantém todos os dados na região original?

Não segundo a documentação atual de preview. Resultados de subconsultas remotas são copiados para tabelas temporárias na região primária e mantidos por 24 horas antes da expiração.

Uma policy de localização impede qualquer processamento fora da região?

Não. Ela limita a criação de recursos suportados conforme a constraint. A documentação alerta que recursos globais ou não suportados ficam fora e que localização do recurso pode diferir do armazenamento ou processamento.

É obrigatório adotar a arquitetura proposta aqui?

Não. Ela é uma recomendação editorial para reduzir dados movimentados. Requisitos contratuais, legais, operacionais e do provedor podem exigir outro desenho ou impedir determinado fluxo.

Qual evidência revisar antes da produção?

Esquema publicado, plano e metadados dos jobs, regiões, bytes copiados, identidades, tabelas temporárias, retenção e testes de rejeição. Revalide a documentação porque o recurso está em preview.