Épico 6 — Seleção de Clínica — Definição (v1.2)
Documentos deste épico: 01 - Definição (v1.2) · 02 - Especificação (v1.2) · 03 - Protótipo (v1.1, código executável em 03 - Protótipo v1.1.html) · 04 - Mapeamento de Banco de Dados (v1.2). Este épico faz parte do documento guarda-chuva Check-in de Usuários.
SEÇÃO 1 — DEFINIÇÃO
Objetivo
Permitir que um profissional autenticado com acesso a mais de uma clínica escolha em qual clínica quer entrar, e — quando há um convite pendente para uma nova clínica — aceitar esse convite sem sair da tela, sem repetir a leitura das regras básicas de uso já lidas no primeiro vínculo (RN-CIU-014, em CIU-E3).
Escopo
Dentro do escopo (nesta revisão):
- Tela de seleção de clínica, exibida quando o roteamento pós-autenticação (RN-CIU-022, no guarda-chuva) chega a “acesso a mais de uma clínica” ou a “convite pendente + ao menos um vínculo ativo”
- Card em destaque para convite pendente, com aceite direto (RN-CIU-025)
Fora do escopo:
- Layout e comportamento das telas de outros épicos do Check-in (E1, E2, E3, E4) — cada um documentado no seu próprio documento
- Definição de quais perfis de acesso existem ou como são criados — pertence ao Contexto de Segurança; este épico apenas consome a verificação (RN-CIU-015, redação completa em CIU-E3)
Personas
- Profissional com acesso a mais de uma clínica — usa esta tela normalmente, toda vez que faz login, para escolher a clínica.
- Profissional com acesso a exatamente 1 clínica e um convite pendente simultâneo — normalmente iria direto ao cockpit (RN-CIU-009, 1 clínica acessível); passa a ver esta tela só para poder aceitar o convite via card (RN-CIU-022, item 2).
- Profissional que acaba de aceitar seu primeiro vínculo (nunca teve nenhum antes) e esse vínculo já dá acesso a mais de uma clínica — chega a esta tela pela primeira vez vindo da tela de aceite do E3 (RN-CIU-014), não de um login com convite pendente: a verificação de Perfil de acesso pós-aceite (RN-CIU-015, em CIU-E3) resulta em mais de 1
ClienteEmpresapara esse único vínculo, e é isso — não um segundo convite — que o traz para cá.
Workflow do Profissional
Resumo: um profissional que atende em mais de uma clínica faz login uma única vez (E1) — a conta é global, compartilhada entre clínicas (RN-CIU-001, em CIU-E1). Depois do login, em vez de cair direto num cockpit, ele escolhe em qual clínica quer trabalhar naquele momento. Se uma clínica nova o convidou nesse meio tempo, ele quer ver e aceitar esse convite no mesmo lugar onde já escolhe a clínica — não numa tela separada, com leitura de regras que ele já leu.
Touchpoint — Seleção de clínica após login:
- Momento do workflow: imediatamente após autenticar-se (E1), quando o roteamento (RN-CIU-022) resulta em acesso a mais de uma clínica, ou em convite pendente com ao menos um vínculo ativo. Também alcançado, sem passar pelo login, ao aceitar o primeiro vínculo no E3 (RN-CIU-014/015), quando esse vínculo já dá acesso a mais de uma clínica.
- Necessidade do profissional: entrar rápido na clínica certa, sem passos extras; e, se houver um convite novo, não ser forçado a uma tela cheia de regras que ele já conhece.
- O que a funcionalidade oferece: lista das clínicas com vínculo ativo + card em destaque para convite pendente, aceito com um clique.
- Decisão de design justificada: o card fica separado da lista normal (destaque visual) porque representa uma ação pendente do profissional, não uma opção de navegação — evita que ele confunda “aceitar convite” com “selecionar clínica”.
Regras de Negócio
- RN-CIU-022 (transversal, redação completa no guarda-chuva) — define quando o roteamento pós-autenticação chega a esta tela.
- RN-CIU-025 — Aceite de convite pendente na tela de seleção de clínica (redação completa abaixo, específica deste épico).
RN-CIU-025 — Aceite de convite pendente na tela de seleção de clínica
Quando o profissional autenticado já tem ao menos um vínculo ativo (UsuarioCliente.Situacao = 'V') e possui, ao mesmo tempo, um convite pendente (Situacao = 'C') para uma nova clínica, o aceite desse convite acontece nesta tela — não na tela de aceite do vínculo do E3 (RN-CIU-014, que a partir desta revisão só se aplica a quem não tem nenhum vínculo ativo). Isso vale mesmo quando o profissional tem acesso a exatamente 1 clínica — caso que, sem convite pendente, iria direto ao cockpit (RN-CIU-009) — pois é o único jeito de esse profissional ver e aceitar o convite (RN-CIU-022, item 2, no guarda-chuva).
A tela de seleção de clínica exibe:
- As clínicas acessíveis (uma por
ClienteEmpresadistinta, agregando todos os vínculos ativos), na lista normal de seleção - Um card em destaque, separado da lista, para cada convite pendente
Diferente da tela de aceite do E3 (RN-CIU-014), este card não exige a leitura das regras básicas de uso da aplicação — o profissional já as leu no momento em que aceitou seu primeiro vínculo. O aceite é uma ação direta no card (ex.: botão “Aceitar”).
Ao aceitar:
- Atualiza o vínculo existente —
UsuarioCliente.Situacaopassa de ‘C’ para ‘V’ (mesmo mecanismo do item 1 de RN-CIU-014; não cria um registro novo) - O card sai da área de destaque; a clínica passa a fazer parte da lista normal de seleção — não é selecionada automaticamente. O profissional precisa de uma segunda ação, a seleção manual da clínica na lista, como faria com qualquer outra. Isso pressupõe que o convite já tinha ao menos uma
ClienteEmpresaassociada no momento do aceite; quando o convite foi criado sem Perfil de acesso/clínica selecionados (RN-CIU-011, em CIU-E3, permite deixar essa seleção pendente), o aceite mudaSituacaopara ‘V’ normalmente, mas nenhuma clínica nova entra na lista — o vínculo fica bloqueado (RN-CIU-015) até o administrador associar Perfil de acesso e clínica(s) posteriormente. [A DEFINIR] — este caso de borda não tem uma identificação visual definida nesta revisão (diferente do card antes do aceite, que já usa o Cliente como fallback — item 4 da lista de propostas abaixo); não resolvido aqui, registrado como pendência. - A verificação de Perfil de acesso (RN-CIU-015) não roda no momento do aceite do card — roda apenas quando o profissional efetivamente seleciona essa clínica na lista, no mesmo momento em que rodaria para qualquer outra clínica selecionada
Premissas
- O profissional só chega a esta tela depois de autenticado (E1) — esta tela nunca é o primeiro ponto de contato com o sistema.
- Toda clínica com vínculo ativo listada aqui já foi aceita em algum momento (E3, RN-CIU-014, ou nesta própria tela, RN-CIU-025) — a tela não lida com convites de clínicas ainda não aceitas de nenhuma forma.
- O profissional pode ter mais de um convite pendente simultâneo (de clínicas diferentes) — cada um exibido como um card separado.
Dependências
Depende do E1 (Núcleo de Identidade e Autenticação) — só é alcançada a partir do roteamento pós-autenticação (RN-CIU-022, documento guarda-chuva). Depende do E3 (Convite e Vínculo) para o mecanismo de aceite de convite (mesma transição de UsuarioCliente.Situacao de ‘C’ para ‘V’, item 1 de RN-CIU-014) e para a verificação de Perfil de acesso pós-seleção (RN-CIU-015, redação completa em CIU-E3) — este épico reaproveita a regra, não a redefine.
Requisitos SBIS Aplicáveis
NGS1.03.01 (Impedir acesso por pessoas não autorizadas), NGS1.03.03 (Gerenciamento de perfis), ECF.17.19 (Mensagens do sistema) — todos estágio 1 (Clínica/ambulatório), obrigatórios. Detalhamento na Seção 2.
Metadados do Épico
| Atributo | Valor |
|---|---|
| Prioridade | Must Have — sem esta tela, um profissional com acesso a mais de uma clínica não tem como escolher onde entrar, e um convite pendente com vínculo já ativo nunca seria visto |
| Complexidade | Baixa — nenhuma tabela nova, reaproveita integralmente a estrutura e as regras de RN-CIU-014/015/024 já mapeadas no E3; a novidade é apenas o momento e o local em que essas regras rodam |
| Dependências | E1 (autenticação, roteamento pós-login); E3 (mecanismo de aceite de vínculo e verificação de Perfil de acesso, reaproveitados sem redefinição) |
| Regras transversais aplicadas | 1 (RN-CIU-022) |
| Regras específicas deste épico | 1 (RN-CIU-025) |
| Histórias de usuário | 2 (US-CIU-006, US-CIU-007) |
| Critérios de aceitação | 9 (CA-006.1 a CA-006.4, CA-007.1 a CA-007.5) |
| Fluxos de exceção | 5 (EX-E6-01 a EX-E6-05) |
| Endpoints | 3 |
| Telas | 1 (Seleção de clínica, com lista + área de destaque de convites) — prototipada em HTML |
| Tabelas utilizadas | 5 existentes (UsuarioCliente, ClienteEmpresa, ClientePerfilAcesso, ClientePerfilAcessoUsuario, UsuarioClienteConvite) — nenhuma nova |
| Mensagens catalogadas | 7 (4 erros, 1 informativa, 2 textos orientadores) + 2 rótulos de botão |
| Requisitos SBIS atendidos | 2 (NGS1.03.01, NGS1.03.03) + ECF.17.19 |
Lista consolidada de itens marcados [PROPOSTA] nesta versão
- Critério de ordenação da lista de clínicas — proposto alfabético por nome, na ausência de indicação do solicitante (Seção 2, Descrição Funcional, “Lista de Clínicas”).
- Fluxo de exceção EX-E6-05 (clínica removida entre carregar a lista e selecionar) — cenário de borda não descrito pelo solicitante; comportamento proposto a confirmar.
- Mensagem MSG-E6-04, associada ao item 2 acima — texto e existência dependem da confirmação do cenário.
- Identificação visual (nome/logo) do card de convite pendente quando o convite ainda não tem nenhuma
ClienteEmpresaassociada ao Perfil de acesso — proposto usar o Cliente como fallback (mesma proposta feita em CIU-E3), a confirmar. - [A DEFINIR] Identificação visual da clínica na lista normal, após o aceite de um convite que não tinha nenhuma
ClienteEmpresaassociada (RN-CIU-025, item 2) — nesse caso não há clínica nova para adicionar à lista; o comportamento correto da tela nesse momento (nenhuma mudança visível além do card sumir? uma mensagem?) não está definido nesta revisão.
Histórico de Versões
- v1.0 (29/08/2026) — Arquivo criado pela divisão do documento único
(CIU-E6) Seleção de Clínica v1.0.mdem arquivos por seção (ver Skill Designer, “Organização Física: Pasta por Funcionalidade”, Lição #18). Conteúdo sem alteração de substância em relação à v1.0 original — apenas reorganização física (o protótipo HTML já era um arquivo separado desde a v1.0 original, só foi renomeado para a convenção nova). Histórico de revisões anterior a esta divisão (v0.1 a v1.0) preservado integralmente no documento original arquivado. - v1.1 (14/09/2026) — corrigido o gatilho desta tela e a Lista de Clínicas: o trocador considerava “mais de um vínculo ativo”; a granularidade correta é “mais de uma clínica (
ClienteEmpresa) acessível”, já que um único vínculo pode compreender mais de umaClienteEmpresa(filiais de uma mesma rede, ou clínicas de um conglomerado sem dados compartilhados). Achado ao consultar a Biblioteca de Schema (DDL) a pedido do solicitante, que confirmou a granularidade e a regra de o administrador escolher clínicas específicas por vínculo (RN-CIU-011, em CIU-E3). TrocadaClienteporClienteEmpresanas tabelas utilizadas. Consequência da mesma correção no E1 (v2.1) e no E3 (v3.2). O protótipo HTML (Seção 3) não precisou de alteração — já exibia um card por clínica individual, compatível com o modelo corrigido. - v1.2 (14/09/2026) — duas correções sobre a v1.1: (1) Personas e Workflow do Profissional passam a reconhecer explicitamente quem chega a esta tela ao aceitar seu primeiro vínculo (E3, RN-CIU-014/015), quando esse vínculo já dá acesso a mais de uma
ClienteEmpresa— cenário que a RN-CIU-015 (CIU-E3) já previa como chegando ao E6, mas que este documento não citava como destino possível; (2) RN-CIU-025, item 2, deixava implícito que toda clínica saída de um card de convite aceito já tem umaClienteEmpresadeterminada — mas RN-CIU-011 (CIU-E3) permite deixar essa seleção pendente no convite. Esse caso de borda (convite aceito sem nenhuma clínica associada) foi identificado e registrado como pendência explícita [A DEFINIR], sem inventar um comportamento novo para ele.