CHECK-IN DE USUÁRIOS NO SISTEMA

Documento pai: Especificação Funcional de Software — Gemed Onco Versão: 2.9 Data: 30/08/2026

1. Objetivo

Definir e especificar todas as funcionalidades relacionadas ao check-in de usuários no sistema Gemed — o conjunto de fluxos que permite que um profissional crie sua conta, autentique-se, recupere seu acesso, seja convidado por clínicas e selecione onde trabalhar.

2. Escopo

2.1 Dentro do escopo

Login com documento único e senha
Controle de tentativas de login com bloqueio parametrizável
Recuperação de senha via código de verificação
Auto-cadastro público (conta global do usuário)
Validação de documento e conselho profissional no cadastro
Dados avançados opcionais conforme SBIS ECF.02.01
Convite de profissionais por clínicas (E3)
Vínculo entre usuário e clínica (E3)
Seleção de clínica quando o usuário possui múltiplos vínculos (a especificar — E6)
Meu Perfil — visualização e edição dos dados do usuário (a especificar — E4)

2.2 Fora do escopo

Single Sign-On (SSO) externo
Gestão de identidade federada
Controle biométrico de acesso
Criptografia de dados em repouso
Gestão de perfis de acesso (RBAC) — tratado no Contexto de Segurança
Gestão de sessão e timeout por inatividade — tratado no Contexto de Segurança

3. Personas

Persona	Descrição
Profissional não cadastrado	Médico, enfermeira, farmacêutica ou outro profissional de saúde que ainda não possui conta no Gemed
Usuário autenticado	Profissional com conta ativa, autenticado no sistema
Administrador da clínica	Usuário com perfil de administrador que convida e vincula profissionais à sua clínica
Suporte técnico Gemed	Usuário N1/N2 que auxilia na resolução de conflitos de cadastro e conselho

4. Workflows do Profissional

Esta seção documenta, uma única vez, os workflows que atravessam mais de um épico do Check-in (conforme a seção “Funcionalidades Grandes: Documento Guarda-Chuva + Documentos Filhos” da Skill Designer). Workflows específicos de um único épico — como a recuperação de senha — ficam documentados no próprio épico dono.

4.1 Entrada do profissional no sistema

Resumo do workflow: todo profissional de saúde ou de apoio precisa, em algum momento, obter uma conta no Gemed e, a partir daí, acessar o sistema no seu dia a dia. Esse workflow tem dois momentos: a criação da conta (uma única vez, se ainda não existir) e o acesso recorrente (a cada dia de trabalho). Ele atravessa os épicos E1 e E2 porque a conta é sempre a mesma (RN-CIU-002 — unicidade global do usuário): quem se cadastra pelo E2 é a mesma pessoa que depois faz login pelo E1.

Touchpoints:

Momento do workflow	Necessidade do profissional	O que a funcionalidade oferece	Decisão de design justificada
Profissional ainda não tem conta no Gemed	Criar sua conta sem depender de um administrador de clínica, e começar a usar o sistema imediatamente	Wizard de auto-cadastro em 3 etapas (E2); ao concluir com sucesso, o sistema autentica o profissional automaticamente e aplica o mesmo roteamento pós-login do E1 (RN-CIU-009 e RN-CIU-022)	Wizard dividido em etapas, não um formulário único, para não sobrecarregar quem só quer os dados básicos — os dados avançados (SBIS ECF.02.01) ficam numa etapa separada e opcional (E2, RN-CIU-018). A autenticação automática ao final evita um segundo passo manual de login logo após o cadastro
Profissional já tem conta e retorna ao sistema (a cada dia de trabalho)	Autenticar rapidamente e ser levado direto ao seu contexto de trabalho, sem etapas extras	Login com documento único + senha (E1); após autenticação, o sistema decide automaticamente para onde direcionar o profissional, conforme seus vínculos com clínicas (E1, RN-CIU-009) — a menos que exista um convite pendente (ver linha abaixo)	O direcionamento automático pós-login (cockpit do profissional / seleção de clínica / Meu Perfil) elimina uma etapa manual de navegação — a decisão de para onde ir é do sistema, não do profissional
Profissional foi convidado por uma clínica (com ou sem conta prévia no Gemed)	Formalizar o vínculo com a clínica que o convidou, sem repetir dados que ela já informou, e sem telas desnecessárias se já usa o sistema em outra clínica	Convite registrado pelo administrador da clínica (E3), que já cria a conta do usuário (Usuario + UsuarioCliente com Situacao = ‘C’, RN-CIU-011). O link do e-mail leva à tela de conclusão de cadastro do E3 (RN-CIU-012) se a senha ainda não foi definida, ou ao login (E1) se já foi (RN-CIU-023). Ao autenticar, com convite pendente: sem nenhum vínculo ativo, vai para a tela de aceite do vínculo do E3 (RN-CIU-014), com leitura das regras básicas; com ao menos um vínculo ativo, o convite aparece como card na tela de seleção de clínica (E6, RN-CIU-025), aceito sem releitura (RN-CIU-022)	Criar a conta já no convite simplifica o modelo de dados e reaproveita a estrutura existente de Usuario/UsuarioCliente. O E2 nunca participa desse fluxo — o CPF já estaria duplicado (RN-CIU-004). O aceite é sempre uma ação explícita; a diferença entre tela cheia (E3) e card (E6) está em quanto o profissional já conhece o sistema — releitura de regras só faz sentido na primeira vez
Profissional esqueceu a senha	Recuperar o acesso sem precisar de suporte técnico	Fluxo de recuperação por código de verificação (E1)	Fica documentado inteiramente em (CIU-E1) — não é um touchpoint transversal, pois não envolve o E2

O roteamento completo pós-autenticação — para onde cada combinação de vínculos ativos e convite pendente leva o profissional — está registrado uma única vez em RN-CIU-022 (Seção 5), não repetido aqui.

5. Regras de Negócio Transversais

Regras que se aplicam a mais de um épico do Check-in de Usuários. A redação completa de cada uma vive aqui — os épicos não a repetem, apenas referenciam o ID (RN-CIU-XXX). Regras que pertencem a um único épico ficam no documento do épico dono (ver Seção 7 — Épicos do Conjunto, para a lista completa de qual RN pertence a qual épico).

RN-CIU-005 — Exclusão lógica (sem campo Status)

O conceito de campo Status foi abolido das tabelas IpSeguranca. A exclusão lógica utiliza a estrutura padrão da infraestrutura:

RemovidoEm (datetimeoffset) — registra a data e hora da exclusão
UsuarioIdRemovido (uniqueidentifier) — identifica quem fez a exclusão

Um registro é considerado ativo quando RemovidoEm é nulo. Um registro é considerado excluído quando RemovidoEm possui uma data/hora preenchida. Todas as consultas, validações e verificações de duplicidade consideram apenas registros ativos.

Usada por: (CIU-E1) — verificação de login e de recuperação de senha; (CIU-E2) — verificação de duplicidade de CPF e de conselho profissional.

RN-CIU-006 — Qualidade e histórico de senha parametrizados

Os seguintes parâmetros de qualidade e histórico de senha são parametrizáveis via tabela UsuarioSenhaParametros (IpSeguranca):

Parâmetro	Descrição	Valor atual
TamanhoMinimo	Mínimo de caracteres na senha	8
MinimoCaracterEspecial	Mínimo de caracteres especiais	1
MinimoLetraMaiuscula	Mínimo de letras maiúsculas	1
MinimoLetraMinuscula	Mínimo de letras minúsculas	1
MinimoNumero	Mínimo de números (dígitos)	1
CaracteresEspeciais	Caracteres especiais válidos aceitos	!@#$%^&*-_+=?;:\|
MinutosValidadeNovaSolicitacao	Validade do código de recuperação (minutos)	15
QuantidadeMemoria	Quantidade de senhas anteriores guardadas (0 = não guarda)	7

Nota: os parâmetros de tentativas de login e bloqueio (QuantidadeTentativas, MinutosBloqueado) não fazem parte desta regra — são específicos do fluxo de login e estão em RN-CIU-010 (CIU-E1). A tabela UsuarioSenhaParametros também guarda, desde a v3.1 do E3, um parâmetro de outra natureza — DiasValidadeConviteVinculo, prazo de validade de convite de vínculo — que também não faz parte desta regra; redação completa em RN-CIU-024 (CIU-E3).

Usada por: (CIU-E1) — redefinição de senha na recuperação; (CIU-E2) — definição de senha no auto-cadastro.

RN-CIU-007 — Suporte multilíngue

O sistema suporta três idiomas: pt-BR (português do Brasil), en-US (inglês) e es-419 (espanhol latino-americano). Todas as mensagens exibidas ao usuário são catalogadas com IDs (MSG-E01, MSG-S01, etc.) e traduzidas para os três idiomas. As mensagens inline nos documentos referenciam os IDs do catálogo.

Usada por: (CIU-E1) e (CIU-E2) — catálogos de mensagens (Seção 10 de cada épico).

RN-CIU-008 — Comportamento de campos de input

Todo campo de input possui um placeholder que é o nome do campo (apenas o nome, sem verbos de comando). Quando o usuário clica no campo para digitar, o placeholder some e se torna um label acima do campo (colado à borda superior do campo). O label é sempre igual ao placeholder.

Usada por: (CIU-E1) e (CIU-E2) — todos os campos de todas as telas.

RN-CIU-022 — Autenticação automática e roteamento pós-autenticação conforme convite pendente (revisada em 27/08/2026, v2.5)

Parte 1 — Autenticação automática pós-auto-cadastro (inalterada desde a v2.1): ao concluir o wizard de auto-cadastro (E2) com sucesso, o sistema autentica o profissional automaticamente — sem exigir um login manual subsequente pela tela do E1.

Parte 2 — Roteamento pós-autenticação: após a autenticação — automática ao final do auto-cadastro (E2), automática ao final da tela de conclusão de cadastro por convite (E3, RN-CIU-012), ou manual pelo login (E1) — o sistema verifica primeiro se existe um convite pendente (UsuarioCliente com Situacao = ‘C’, E3, RN-CIU-011) associado ao usuário, e cruza com a existência de vínculo(s) ativo(s) (Situacao = ‘V’):

Convite pendente e nenhum vínculo ativo — o profissional é genuinamente novo no sistema. É direcionado para a tela de aceite do vínculo (E3, RN-CIU-014), antes de qualquer outro destino, com leitura das regras básicas de uso. Somente após o aceite, com a verificação de Perfil de acesso (E3, RN-CIU-015), o profissional chega à sua tela inicial de fato (cockpit, se há perfil; mensagem de bloqueio orientativa, se não há).
Convite pendente e ao menos um vínculo ativo — o profissional já usa o sistema em outra(s) clínica(s). O aceite não passa pela tela de aceite do E3 — é direcionado para a tela de seleção de clínica (E6), que exibe um card em destaque com o convite pendente, aceito diretamente ali, sem releitura das regras básicas (E6, RN-CIU-025). Isso vale mesmo quando há só 1 vínculo ativo — que, sem convite pendente, iria direto ao cockpit (item 3).
Sem convite pendente — aplica-se o roteamento padrão por vínculos ativos, já descrito em RN-CIU-009: 0 vínculos ativos → Meu Perfil (E4) com banner MSG-I01; 1 vínculo ativo → cockpit do profissional; múltiplos vínculos ativos → seleção de clínica (E6).

O caso do auto-cadastro público (E2) recai sempre no item 3, com 0 vínculos ativos — resultando no direcionamento a Meu Perfil, exatamente como descrito na decisão original da v2.1: quem se cadastra pelo E2 nunca tem convite pendente, pois se tivesse, o CPF já pertenceria a uma conta criada pelo administrador e o cadastro teria sido bloqueado por duplicidade (RN-CIU-004). Um profissional convidado (itens 1 ou 2) chega pela tela de conclusão de cadastro ou pelo login do E1 — nunca pelo E2 — e segue um caminho diferente antes de chegar a qualquer tela final.

A aplicação da verificação de convite pendente ao fluxo de login manual (E1) — item 2 acima em particular — foi confirmada pelo solicitante em 27/08/2026: um usuário já existente que recebe um convite de uma nova clínica vê o convite ao fazer login, mas não é interrompido pela tela cheia de aceite do E3 — o convite aparece como card na tela que ele já usa para escolher a clínica.

Usada por: (CIU-E2) — tela de sucesso do wizard, ao final da Etapa 3 (verificação de convite pendente sempre negativa, por construção — ver Seção 1.2 do E2); (CIU-E1) — reaproveita o mecanismo de autenticação e passa a consultar convitesPendentes na resposta do login (Seção 9.1 do E1) antes de aplicar o roteamento por vínculos (RN-CIU-009); (CIU-E3) — dona da tela de conclusão de cadastro (que também autentica automaticamente ao final, RN-CIU-012), da tela de aceite do vínculo (item 1) e da verificação de Perfil de acesso; (CIU-E6) — dona da tela de seleção de clínica e do card de aceite (item 2, RN-CIU-025).

6. Requisitos SBIS Aplicáveis

Requisito	Estágio	Descrição	Épicos que atendem
ECF.02.01	1 (obrigatório)	Identificação dos profissionais — campos presentes no formulário	E2
ECF.02.02	1 (obrigatório)	Duplicidade de cadastros — validação por CPF e conselho	E2
NGS1.02.01	1 (obrigatório)	Método de autenticação — usuário + senha, validação no servidor	E1
NGS1.02.02	1 (obrigatório)	Proteção dos parâmetros de autenticação — hash de no mínimo 160 bits	E1
NGS1.02.03	1 (obrigatório)	Qualidade da senha — mínimo 8 caracteres, 1 alfabético, 1 numérico	E1, E2
NGS1.02.11	1 (obrigatório)	Igualdade de senhas — nova senha diferente da atual e da imediatamente anterior	E1
NGS1.02.12	1 (obrigatório)	Obtenção de nova senha — opção “esqueci a senha” na tela de login	E1
NGS1.02.13	1 (obrigatório)	Controle de tentativas de login — bloqueio após máximo configurável (≤10)	E1
NGS1.02.16	1 (obrigatório)	Informações em autenticação inválida — mensagem genérica sem revelar motivo	E1
NGS1.02.17	1 (obrigatório)	Revelação de credenciais — máscara de caracteres, sem memorização	E1, E2
NGS1.02.19	2 (recomendado)	Uso de SALT — novo salt para cada senha	E1, E2
ECF.17.19	1 (obrigatório)	Mensagens do sistema — linguagem não técnica em português do Brasil	E1, E2, E3
NGS1.03.01	1 (obrigatório)	Impedir acesso por pessoas não autorizadas — permissões atribuídas a perfis de usuário	E3
NGS1.03.03	1 (obrigatório)	Gerenciamento de perfis — cadastro, ativação/inativação, atribuição de permissões	E3
NGS1.03.08	1 (obrigatório)	Gerenciamento de usuários — cadastro, ativação/inativação, alteração	E3
NGS1.03.09	1 (obrigatório)	Identidade única da pessoa e responsabilização — unicidade de CPF	E1, E2, E3

7. Épicos do Conjunto

7.1 Status e versões

Épico	Título	Status	Versão	Dependências
E1	Núcleo de Identidade e Autenticação	✅ Finalizado (Seção 1-4 completas)	v2.0	Nenhuma (épico base)
E2	Auto-cadastro Público	✅ Finalizado (Seção 1-4 completas; pendências de BD registradas em Seção 4 do épico)	v2.0	E1
E3	Convite e Vínculo	✅ Finalizado (Seção 1-4 completas)	v3.1	E1 (reaproveita definições de campo do E2, sem depender do fluxo)
E4	Meu Perfil	⏳ A especificar	—	E1, E2
E6	Seleção de Clínica	✅ Finalizado (Seção 1-4 completas)	v1.0	E1 (roteamento pós-login); E3 (reaproveita aceite de vínculo e verificação de Perfil de acesso)

7.2 Regras de negócio específicas de cada épico

As regras abaixo pertencem a um único épico — a redação completa está no documento do épico correspondente. Aqui consta apenas a referência, para não duplicar conteúdo.

RN	Título	Épico dono
RN-CIU-001	Documento único como chave de identificação	(CIU-E1), Seção 2
RN-CIU-002	Unicidade global do usuário	(CIU-E2), Seção 2
RN-CIU-003	Campos do auto-cadastro	(CIU-E2), Seção 2
RN-CIU-004	Validação de documento no cadastro	(CIU-E2), Seção 2
RN-CIU-009	Autenticação	(CIU-E1), Seção 2
RN-CIU-010	Tentativas de login (parametrizável)	(CIU-E1), Seção 2
RN-CIU-013	Auto-cadastro não gera vínculo	(CIU-E2), Seção 2
RN-CIU-016	Sem validação de formato nem máscara no login	(CIU-E1), Seção 2
RN-CIU-017	Estrutura genérica de conselho profissional	(CIU-E2), Seção 2
RN-CIU-018	Dados avançados opcionais (SBIS ECF.02.01)	(CIU-E2), Seção 2
RN-CIU-019	Identificação do tipo de profissional	(CIU-E2), Seção 2
RN-CIU-020	Máscara de celular parametrizada por país	(CIU-E2), Seção 2
RN-CIU-021	Documentos condicionais por nacionalidade	(CIU-E2), Seção 2
RN-CIU-011	Convite de profissional pela clínica	(CIU-E3), Seção 2
RN-CIU-012	Tela de conclusão de cadastro para convite	(CIU-E3), Seção 2
RN-CIU-014	Tela de aceite do vínculo	(CIU-E3), Seção 2
RN-CIU-015	Verificação de Perfil de acesso pós-aceite	(CIU-E3), Seção 2
RN-CIU-023	Roteamento do link de convite conforme senha já definida	(CIU-E3), Seção 2
RN-CIU-024	Expiração e cancelamento de convite [PROPOSTA]	(CIU-E3), Seção 2
RN-CIU-025	Aceite de convite pendente na tela de seleção de clínica	(CIU-E6), Seção 2

7.3 Resumo dos épicos finalizados

E1 — Núcleo de Identidade e Autenticação (v2.0): Tela de login com documento único + senha, sem máscara nem validação de formato (anti-enumeração). Controle de tentativas parametrizável (QuantidadeTentativas = 5, MinutosBloqueado = 15). Recuperação de senha em 2 etapas com código de 6 dígitos, dupla verificação de documento e critérios de complexidade parametrizados. Antes de aplicar o roteamento por vínculos, verifica convite pendente (UsuarioCliente com Situacao = ‘C’, RN-CIU-022) e direciona para a tela de aceite do vínculo (E3) quando aplicável; um vínculo só é considerado ativo, para fins de roteamento, quando Situacao = ‘V’ (RN-CIU-009, redefinido conforme o domínio C/V/B criado no E3). Mensagens multilíngues (pt-BR, en-US, es-419). Reconstruído no modelo padrão Seção 1-4 (v2.0, 30/08/2026) — deixa de ser legado. 2 histórias de usuário, 19 critérios de aceitação, 6 fluxos de exceção, 4 endpoints, 4 tabelas (todas existentes).

E2 — Auto-cadastro Público (v2.0): Wizard de 3 etapas (dados básicos com complemento profissional condicional, dados avançados opcionais, definição de senha). Validação de CPF com dígitos verificadores. Verificação de duplicidade de CPF e conselho em tempo real. Estrutura genérica de conselho profissional (tipo, número, UF). Identificação de tipo de profissional de saúde (médico, enfermeira, farmacêutica, psicólogo, etc.). Documentos condicionais por nacionalidade. Dados avançados opcionais conforme SBIS ECF.02.01. Máscara de celular parametrizada por país. Conflito de conselho não bloqueia o cadastro — permite concluir sem conselho. Ao final, autentica automaticamente e direciona sempre para Meu Perfil (RN-CIU-022) — este épico nunca é acessado por quem foi convidado por uma clínica, pois o CPF já estaria cadastrado pelo administrador (RN-CIU-004): a pessoa convidada usa a tela de conclusão de cadastro do E3, não este wizard. Reconstruído no modelo padrão Seção 1-4 (v2.0, 30/08/2026) — deixa de ser legado; as pendências de banco de dados (campos avançados SBIS, estrutura de conselho, tabelas de terminologia) foram trazidas para a Seção 4 do próprio épico (ver Seção 9 abaixo). 2 histórias de usuário, 22 critérios de aceitação, 6 fluxos de exceção, 4 endpoints, 4 tabelas existentes.

E3 — Convite e Vínculo (v3.1): Administrador da clínica cadastra CPF, e-mail, celular e nome de um profissional, o que cria diretamente a conta (Usuario, sem senha) e o vínculo em situação de convite (UsuarioCliente com Situacao = ‘C’, RN-CIU-011), e dispara um e-mail com link de convite. O link leva a uma tela própria de conclusão de cadastro (RN-CIU-012, confirmação/complemento de dados + definição de senha) se a senha ainda não foi definida, ou ao login normal (E1) se já foi (RN-CIU-023). Ao autenticar sem nenhum vínculo ativo, convite pendente direciona para a tela de aceite do vínculo — leitura das regras básicas e aceite explícito, que atualiza o vínculo existente para Situacao = ‘V’ (RN-CIU-014; com ao menos um vínculo ativo, o aceite ocorre em E6, RN-CIU-025). Administrador pode selecionar o Perfil de acesso já no cadastro do convite; se não, verifica Perfil de acesso associado após o aceite: se existe, segue para o cockpit; se não existe, exibe mensagem orientando a aguardar ou contatar o administrador. Token e prazo de validade do convite não são atributos de UsuarioCliente (o vínculo permanente) — ficam em tabela complementar nova, UsuarioClienteConvite, com dado apagado fisicamente assim que o convite é resolvido (aceito, cancelado ou expirado); prazo parametrizado em 7 dias (UsuarioSenhaParametros.DiasValidadeConviteVinculo). Convite expirado sem senha nunca definida: rotina periódica exclui logicamente Usuario + UsuarioCliente. Restruturado no modelo padrão da Skill Designer (Seção 1-4, v3.0); v3.1 confirmou as últimas 4 propostas em aberto. 2 histórias de usuário, 13 critérios de aceitação, 7 fluxos de exceção (todos confirmados), 6 endpoints, 5 tabelas existentes, 1 tabela nova (UsuarioClienteConvite). Seção 3 (Protótipo HTML) ainda pendente.

E6 — Seleção de Clínica (v1.0): Tela exibida após o login quando o profissional tem mais de um vínculo ativo, ou tem ao menos um vínculo ativo e um convite pendente simultâneo (RN-CIU-022, item 2). Lista as clínicas com vínculo ativo (nome e logo, de Cliente) e, separado dela, um card em destaque por convite pendente, aceito sem releitura das regras básicas (RN-CIU-025) — aceitar não seleciona a clínica automaticamente, apenas a adiciona à lista, e a verificação de Perfil de acesso (RN-CIU-015, reaproveitada do E3) só roda na seleção manual, não no aceite. Nenhuma tabela nova — reaproveita integralmente UsuarioCliente, Cliente, ClientePerfilAcesso, ClientePerfilAcessoUsuario e UsuarioClienteConvite, já mapeadas no E3. 2 histórias de usuário, 9 critérios de aceitação, 5 fluxos de exceção (um marcado como proposta — cenário de borda), 3 endpoints, protótipo HTML produzido nesta versão.

8. Convenções de Documentação

Estrutura de cada épico

Cada épico é uma instância completa da metodologia Skill Designer — Seção 1 (Definição), Seção 2 (Especificação), Seção 3 (Protótipo HTML) e Seção 4 (Mapeamento de Banco de Dados), restrita ao escopo daquele épico (ver “Funcionalidades Grandes: Documento Guarda-Chuva + Documentos Filhos” na Skill Designer). Não há uma estrutura própria de épico definida neste documento — a estrutura vive em um lugar só, na Skill Designer, e vale tanto para um documento único quanto para cada filho de um guarda-chuva.

Não há mais épicos legados neste conjunto. E1 e E2 foram construídos originalmente com uma estrutura própria de 12 itens (Visão Geral, Regras de Negócio, Histórias de Usuário, Descrição Funcional, Critérios de Aceitação, Fluxos de Exceção, Validações de Campos, Mapeamento de Componentes, Integração com Backend, Catálogo de Mensagens, Conformidade SBIS, Metadados) — sem Seção 3 (Protótipo HTML) nem Seção 4 (Mapeamento de BD) completa. Reconstruídos integralmente no modelo padrão Seção 1-4 em 30/08/2026 (E1 v1.9 → v2.0, E2 v1.6 → v2.0), a pedido do solicitante — mesmo tratamento já aplicado ao E3 (v2.1 → v3.0); E4 e E6 em diante já seguiam a Seção 1-4 da Skill Designer desde a criação.

Dois itens da estrutura legada provaram valor e foram promovidos ao padrão único da Skill Designer — deixam de ser exclusividade de épico: Fluxos de Exceção como catálogo com ID próprio (não só um bullet) e Catálogo de Mensagens do Sistema e Termos de Interface (i18n) como sub-seção oficial. Ambos agora fazem parte da Seção 2 — Especificação de qualquer documento deste projeto, não só de épicos.

Numeração

Regras de negócio: RN-CIU-XXX (CIU = Check-in de Usuários)
Histórias de usuário: US-CIU-XXX
Critérios de aceitação: CA-XXX.X
Fluxos de exceção: EX-EXX-XX, vinculado ao épico (ex.: EX-E3-01) — corrigido nesta revisão: a prática real desde o E1 já segue esse padrão por épico, não o “EX-XXX global” descrito em revisões anteriores deste documento
Mensagens: MSG-EXX (erro), MSG-SXX (sucesso), MSG-IXX (informativa), MSG-PXX (placeholder), MSG-TXX (texto orientador), MSG-BXX (botão/link), MSG-CXX (checkbox)

Separação de preocupações

Regras de Negócio: descrevem o que o sistema faz, em linguagem de negócio. Sem nomes de tabelas, campos ou mecanismos técnicos.
Descrição Funcional: descreve como o sistema funciona, incluindo detalhes técnicos (campos de banco, mecanismos de hash/salt, etc.).
Mapeamento de Tabelas: lista as tabelas e campos utilizados, com o banco de dados correspondente.

9. Bancos de Dados Utilizados

Banco	Descrição	Uso no Check-in
IpSeguranca	Segurança e configuração	Tabelas Usuario, UsuarioSenhaHistorico, UsuarioSenhaParametros, UsuarioCliente
IpTerminologia	Tabelas de domínio	Listas de tipos de conselho, tipos de profissional, especialidades, CBO

Tabelas existentes utilizadas

Tabela	Banco	Épicos
Usuario	IpSeguranca	E1, E2, E3
UsuarioSenhaHistorico	IpSeguranca	E1, E2
UsuarioSenhaParametros	IpSeguranca	E1, E2
UsuarioCliente	IpSeguranca	E1, E2, E3
ClientePerfilAcesso	IpSeguranca	E3
ClientePerfilAcessoUsuario	IpSeguranca	E3

Campos e tabelas a criar (pendências de BD)

Campos de dados avançados (SBIS ECF.02.01), estrutura genérica de conselho profissional/tipo de profissional e tabelas de terminologia (IpTerminologia) — pendências do E2, consolidadas na Seção 4 do próprio épico desde 30/08/2026 (antes viviam apenas aqui, como nota textual sem seção própria — Lição #10 da Skill Designer: uma informação em um lugar só). Ver (CIU-E2), Seção 4, “Pendências de banco de dados”.
[PROPOSTA] Domínio do campo UsuarioCliente.Situacao (IpSeguranca) — C (Convidado), V (Vinculado), B (Bloqueado); não documentado anteriormente em EsquemaGemed21.csv.
[PROPOSTA] Tabela nova UsuarioClienteConvite (IpSeguranca) — token e prazo de validade do convite não são atributos do vínculo permanente (UsuarioCliente), por isso ficam numa tabela complementar própria, útil apenas entre o convite e sua resolução (aceite, cancelamento ou expiração), quando o registro é apagado fisicamente. PK/FK UsuarioClienteId → UsuarioCliente.Id, campos Token e DataExpiracao. Substitui a proposta anterior de duas colunas (TokenConvite, DataExpiracaoConvite) na própria tabela UsuarioCliente — rejeitada pelo solicitante em 27/08/2026 por não pertencerem à entidade de vínculo. Detalhamento completo, com justificativa da modelagem, em (CIU-E3), Seção 4.

10. Metadados

Atributo	Valor
Funcionalidade pai	Check-in de Usuários no Sistema
Workflows do profissional documentados	1 (Entrada do profissional no sistema — E1 + E2)
Épicos finalizados	4 (E1 v2.0, E2 v2.0, E3 v3.1, E6 v1.0) — nenhum épico legado; todos no modelo padrão Seção 1-4
Épicos pendentes	1 (E4)
Regras de negócio transversais (redação completa nesta seção)	5 (RN-CIU-005, 006, 007, 008, 022 — RN-CIU-022 revisada em 27/08/2026, v2.5)
Regras de negócio específicas de épico (referenciadas aqui)	20 (RN-CIU-001, 002, 003, 004, 009, 010, 011, 012, 013, 014, 015, 016, 017, 018, 019, 020, 021, 023, 024, 025)
Requisitos SBIS aplicáveis	16
Bancos utilizados	2 (IpSeguranca, IpTerminologia)
Tabelas existentes utilizadas	6
Pendências de BD	4 grupos (dados avançados, conselho genérico, terminologias, domínio Situacao [PROPOSTA] + tabela UsuarioClienteConvite [PROPOSTA])
Idiomas suportados	3 (pt-BR, en-US, es-419)

11. Histórico de Versões

v1.0 (12/08/2026) — versão original, 9 regras de negócio transversais (incluía regras que hoje são específicas de épico).
v1.1 (27/08/2026) — numeração de RN reorganizada: 4 regras verdadeiramente transversais com redação única aqui; as demais movidas para o épico dono, apenas referenciadas aqui.
v2.0 (27/08/2026) — estrutura reorganizada conforme a nova seção “Funcionalidades Grandes: Documento Guarda-Chuva + Documentos Filhos” da Skill Designer: adicionada a Seção 4 (Workflows do Profissional, antes inexistente); consolidada em uma única tabela (Seção 7.2) a lista de RN específicas por épico, que antes vivia apenas ao final da Seção 5; Requisitos SBIS movidos para logo após as Regras de Negócio (Seção 6), refletindo a ordem Definição → RN → SBIS da metodologia.
v2.1 (27/08/2026) — resolvida a lacuna registrada na v2.0 sobre o handoff E2→E1: confirmado que o auto-cadastro autentica automaticamente o profissional ao final, direcionando para Meu Perfil (decisão do usuário do projeto, 27/08/2026). Criada RN-CIU-022 (transversal) para registrar essa decisão; atualizados a Seção 4.1 (touchpoint e nota) e os Metadados.
v2.2 (27/08/2026) — correção da RN-CIU-022: a decisão da v2.1 cobria apenas o auto-cadastro sem convite (permanece correta para esse caso). Adicionado o segundo cenário, descrito pelo solicitante no mesmo dia: profissional convidado por uma clínica (E3) antes de se cadastrar ou logar. RN-CIU-022 reescrita para descrever o roteamento por convite pendente, cobrindo ambos os cenários; a extensão da verificação de convite ao fluxo de login (E1), além do pós-cadastro (E2), é uma proposta de consistência não explicitamente confirmada pelo solicitante (marcada como tal na própria regra). Adicionado o Épico 3 (Convite e Vínculo, v1.0), elaborado nesta mesma revisão — inclui a proposta de tabela nova Convite (IpSeguranca), não existente em EsquemaGemed21.csv. Atualizadas as Seções 2, 4, 5, 6, 7, 9, 10 e este Histórico.
v2.3 (27/08/2026, mesmo dia) — atualização de referência: o Épico 3 foi revisado para v1.1 (duas correções do solicitante na RN-CIU-015 — projeto não possui DOC-001 acessível, referência removida; “Perfil de acesso” esclarecido como distinto de “perfil profissional”). Nenhum conteúdo deste documento guarda-chuva foi alterado além da atualização do número de versão do E3 nas Seções 7.1, 7.3, 10 e neste Histórico.
v2.4 (27/08/2026, mesmo dia) — arquitetura de convite redesenhada, a pedido do solicitante: em vez de uma tabela nova Convite, o administrador cria a conta do usuário diretamente ao registrar o convite (Usuario + UsuarioCliente com Situacao = ‘C’ — domínio C/V/B definido nesta revisão, RN-CIU-011 em (CIU-E3)). O roteamento do link de convite passou a se basear na existência de senha (Usuario.Hash nulo ou não — RN-CIU-023), em vez de na existência prévia de Usuario; quem ainda não definiu senha vai a uma tela própria de conclusão de cadastro do E3 (RN-CIU-012), não mais ao auto-cadastro pré-preenchido do E2. Como consequência: o E2 (v1.6) reverteu integralmente sua participação no fluxo de convite — nunca é alcançado por uma pessoa convidada, pois o CPF já estaria duplicado (RN-CIU-004); o E1 (v1.9) corrigiu a definição de “vínculo ativo” (RN-CIU-009) para exigir Situacao = ‘V’, não apenas RemovidoEm nulo; o E3 foi reescrito integralmente (v2.0). Atualizadas as Seções 4, 5 (RN-CIU-022), 7, 9, 10 e este Histórico.
v2.5 (27/08/2026, mesmo dia) — RN-CIU-022 refinada, a pedido do solicitante, resolvendo a proposta sinalizada na v2.4 sobre estender a verificação de convite pendente ao login manual (E1): confirmado que se aplica, mas com um desdobramento novo — profissional com pelo menos um vínculo ativo que recebe um convite não passa mais pela tela cheia de aceite do E3 (RN-CIU-014, agora escopada a quem não tem nenhum vínculo ativo); o convite aparece como card na tela de seleção de clínica (E6), aceito sem releitura das regras básicas, já lidas no primeiro vínculo. Criada RN-CIU-025 (específica do E6, referenciada na Seção 7.2) e ajustada RN-CIU-014 em (CIU-E3), que passou para v2.1. Seção 8 (Convenções de Documentação) reescrita: épicos deixam de ter uma estrutura própria de 12 itens e passam a usar a Seção 1-4 da Skill Designer, como qualquer documento — E1/E2/E3 mantidos como legado, sem reestruturação retroativa; Fluxos de Exceção e Catálogo de Mensagens/i18n promovidos a sub-seções oficiais da Seção 2 na Skill Designer. Corrigida também a convenção de numeração de Fluxos de Exceção nesta seção (EX-EXX-XX por épico, refletindo a prática já usada desde o E1 — não o “EX-XXX global” que estava documentado).
v2.6 (27/08/2026, mesmo dia) — Seção 4.1 (“Entrada do profissional no sistema”) consolidada a pedido do solicitante: a linha da tabela de touchpoints sobre “profissional convidado por uma clínica” foi reescrita para refletir, num texto coeso, o roteamento já registrado em RN-CIU-022 (Seção 5); os parágrafos fragmentados que narravam o histórico da decisão (várias correções e ampliações sucessivas ao longo do dia) foram removidos do corpo — essa narrativa já está preservada neste Histórico de Versões (entradas v2.1 a v2.5) — e substituídos por uma única frase de referência cruzada a RN-CIU-022. Nota de processo: esta consolidação havia sido aplicada diretamente no arquivo de trabalho antes desta entrada, sem arquivamento prévio da v2.5 nem registro de versão — falha na disciplina de versionamento do próprio projeto. Corrigida agora: a v2.5 (já incluindo a consolidação da Seção 4.1) foi arquivada em Histórico/ antes desta v2.6, e o incidente está registrado aqui para rastreabilidade. Seção 9 (“Campos e tabelas a criar”) atualizada: a proposta de duas colunas (TokenConvite, DataExpiracaoConvite) em UsuarioCliente foi rejeitada pelo solicitante — token e data de expiração não são atributos do vínculo permanente — e substituída pela proposta de tabela complementar nova UsuarioClienteConvite, detalhada em (CIU-E3), Seção 4. Seções 7.1, 7.3 e 10 atualizadas para refletir a reconstrução do Épico 3 no modelo padrão da Skill Designer (v3.0, Seção 1-4 completas) e o estágio atual do Épico 6 (v0.1, Seção 1 concluída — antes não refletido nestas tabelas).
v2.7 (27/08/2026, mesmo dia) — Épico 6 completado no modelo padrão Seção 1-4 (v1.0): Seções 2, 3 e 4 desenvolvidas, com protótipo HTML produzido. Confirma que nenhuma tabela nova é necessária — reaproveita integralmente a estrutura já mapeada em CIU-E3. Seções 7.1, 7.3 e 10 deste guarda-chuva atualizadas: E6 passa de “em definição” para “finalizado”; adicionado o resumo do Épico 6 à Seção 7.3, junto aos demais épicos finalizados; contagem de épicos finalizados em 10 passa de 3 para 4. Seção 8 corrigida: a nota “Legado (E1, E2, E3)” estava desatualizada desde a v2.6 (quando o E3 deixou de ser legado) — agora lista corretamente apenas E1 e E2 como legado.
v2.8 (27/08/2026, mesmo dia) — quatro propostas do E3 confirmadas pelo solicitante, refletidas no épico (v3.1) e propagadas até aqui: prazo de validade do convite (7 dias) parametrizado em UsuarioSenhaParametros.DiasValidadeConviteVinculo, mesma tabela usada pelos parâmetros de senha (RN-CIU-006) — nota cruzada adicionada a RN-CIU-006 apontando para RN-CIU-024 (CIU-E3), para deixar claro que a tabela agora serve dois propósitos distintos. Seções 7.1 e 7.3 atualizadas com a versão e o resumo do E3 (v3.1): 5 tabelas existentes (adicionada UsuarioSenhaParametros), 7 fluxos de exceção todos confirmados, seleção de Perfil de acesso já no convite e rotina de expiração confirmadas.
v2.9 (30/08/2026) — E1 e E2 reconstruídos integralmente no modelo padrão Seção 1-4 da Skill Designer, a pedido do solicitante (“recrie CIU-E1 e CIU-E2 no novo formato”) — E1 de v1.9 para v2.0, E2 de v1.6 para v2.0 — mesmo tratamento já aplicado ao E3 (v2.1 → v3.0). Este conjunto não tem mais nenhum épico legado (Seção 8 corrigida). As pendências de banco de dados do E2 (campos avançados SBIS ECF.02.01, estrutura genérica de conselho, tabelas de terminologia), antes registradas apenas na Seção 9 deste documento, foram consolidadas na Seção 4 do próprio épico (CIU-E2) — este documento passa a apenas referenciá-las (Lição #10 da Skill Designer: uma informação em um lugar só); nenhuma delas foi resolvida, seguem [A DEFINIR]. Seções 7.1, 7.3, 8, 9 e 10 atualizadas. Nome do arquivo deste documento atualizado de 00 - Guarda-chuva v2.8.md para 00 - Guarda-chuva v2.9.md — cabeçalho de irmãos de (CIU-E3) e (CIU-E6) atualizado para apontar para o novo nome.

Gemed 2.1 — Documentação

Explorador

00 - Guarda-chuva v2.9