Clinic Revenue OS para redes de clínicas com múltiplas unidades

Como funciona o isolamento entre as unidades de uma rede?

Toda consulta ao banco de dados do Clinic Revenue OS já nasce filtrada pela clínica do usuário logado, por Row Level Security (RLS) — não é uma regra aplicada depois, na tela; é uma restrição no próprio banco. Isso significa que, tecnicamente, uma unidade não consegue ler dado de outra unidade mesmo que exista um erro de tela ou de lógica no aplicativo.

Esse desenho evita a classe de erro mais comum em sistema multiunidade mal feito: um filtro esquecido numa tela específica que deixa vazar dado de paciente de uma unidade para outra. Aqui a barreira está numa camada abaixo da interface.

Na prática, isso tira da equipe de TI da rede a responsabilidade de configurar regra de acesso unidade por unidade dentro do próprio aplicativo. A barreira já vem pronta no banco, independente de qual tela o usuário abre ou de qual módulo — Modo Dono, Cofre de Receita, Radar de Cadeira Vazia — está sendo consultado no momento.

Como um usuário troca de unidade sem precisar de outro login?

Uma rede com várias unidades não precisa de uma conta separada por unidade. O mesmo usuário logado troca de unidade dentro da mesma sessão, através de um endpoint próprio de troca de clínica — o sistema atualiza o recorte de dados e os módulos (Modo Dono, Dinheiro Vazando, Radar de Cadeira Vazia e os demais) passam a mostrar a unidade selecionada.

Isso poupa a gestão de credenciais: quem circula entre unidades — dono de rede, gerente regional, financeiro — não precisa memorizar senha por unidade nem fazer logout e login toda vez que muda de endereço.

O ganho é sobretudo operacional: uma visita presencial a uma unidade diferente, ou uma reunião de revisão com o gerente daquele endereço, não exige preparo prévio de acesso. A troca acontece dentro da mesma sessão, no momento em que é necessária.

Como a gestão de unidades funciona dentro da mesma organização?

Existe uma gestão de unidades própria dentro do produto: listar as unidades da clínica, criar uma unidade nova, editar dados de uma unidade existente ou remover uma unidade, cada ação com seu endpoint dedicado.

Isso mantém a estrutura organizacional dentro de um único cadastro de rede — a unidade é uma entidade gerenciável, não uma conta paralela criada por fora do sistema.

Abrir uma unidade nova, por exemplo, não exige provisionar um ambiente separado ou negociar uma nova assinatura isolada: é um cadastro dentro da organização já existente, usando a mesma estrutura de permissão que as demais unidades já usam.

Papel e permissão são os mesmos em todas as unidades da rede?

Não necessariamente. Cada usuário pode ter papel (role) e permissões específicas por unidade dentro da mesma organização — quem administra a unidade A não precisa ter o mesmo nível de acesso na unidade B.

Isso serve tanto para separar operação de gestão (recepção de uma unidade não precisa ver o financeiro de outra) quanto para o caso comum em rede: um gerente que responde por duas unidades específicas, não pela rede inteira.

Essa granularidade por unidade segue o mesmo princípio já usado dentro de uma única clínica, onde cada módulo — Dinheiro Vazando, Radar de Cadeira Vazia, Cofre de Receita — exige sua própria permissão. Numa rede, essa mesma permissão pode ainda ser restrita a uma unidade específica, não à organização toda.

O que o MVP ainda não entrega para quem administra a rede toda?

Hoje o MVP não tem uma visão consolidada automática que some todas as unidades numa única tela. O fluxo real é: o usuário troca de unidade pelo endpoint de troca de clínica e vê os módulos — Modo Dono, Dinheiro Vazando, Radar de Cadeira Vazia — daquele recorte específico, unidade por vez.

Isso é uma limitação honesta do estágio atual do produto, não uma promessa que foi feita e não foi cumprida. Quem administra três, quatro ou mais unidades hoje soma o que vê manualmente, trocando de tela a cada unidade revisada.

Por que dizer isso de forma explícita em vez de deixar a rede descobrir sozinha?

Porque uma rede que decide adotar o produto esperando um painel único somado, e só descobre a limitação depois de integrar dados de várias unidades, perde tempo de operação e confiança no fornecedor. Documentar o limite do MVP antes da decisão é mais barato para os dois lados do que corrigir a expectativa depois.

A mesma lógica vale para as estimativas de receita mostradas dentro de cada módulo: elas apoiam a priorização operacional da unidade, não são garantia de resultado — e isso vale unidade por unidade, do mesmo jeito.

O isolamento entre unidades é um recurso à parte criado só para redes?

Não. É o mesmo mecanismo de segurança — Row Level Security no banco — que a Centriu usa para separar dado de paciente entre clientes completamente diferentes da plataforma, cada um sua própria clínica sem nenhuma relação entre si.

Uma rede multiunidade, dentro dessa lógica, é tratada como uma organização com várias unidades associadas a ela; duas clínicas de donos diferentes são duas organizações sem nenhuma associação. O motor de isolamento é o mesmo nos dois casos — só muda o que está associado a quem dentro da estrutura.

O que isso significa na prática para quem avalia o produto para uma rede?

Significa que a base de segurança multiunidade não é um recurso experimental construído por cima de um produto pensado para clínica única — é o mesmo alicerce usado para isolar qualquer clínica cliente da plataforma, testado em todo cliente, não só em redes.

E significa também que, hoje, avaliar o produto para uma rede exige aceitar que a consolidação entre unidades ainda é manual, unidade por unidade, enquanto isolamento, troca de unidade e permissão por unidade já funcionam dentro da mesma conta.