# CHECK-IN DE USUÁRIOS NO SISTEMA Documento pai: Especificação Funcional de Software — Gemed Onco Versão: 2.4 Data: 27/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 todos os dados que ela já informou|Convite registrado pelo administrador da clínica (E3), que já cria a conta do usuário (Usuario + UsuarioCliente com Situacao = 'C', RN-CIU-011) — não existe mais um convite "solto" sem conta associada. 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); em ambos os casos, ao autenticar, a existência de convite pendente (Situacao = 'C') direciona para a tela de aceite do vínculo (E3) antes de qualquer outro destino (RN-CIU-022)|Criar a conta já no convite (em vez de um registro solto pré-conta) simplifica o modelo de dados e reaproveita a estrutura existente de Usuario/UsuarioCliente. O E2 (auto-cadastro público) nunca participa desse fluxo — se a pessoa convidada tentasse se auto-cadastrar, o CPF já estaria duplicado (RN-CIU-004). O aceite continua sendo uma ação explícita, não implícita no cadastro ou login — o profissional precisa confirmar conscientemente o vínculo antes de ganhar acesso a dados da clínica| |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| **Decisão confirmada (27/08/2026):** ao concluir o auto-cadastro (E2), o profissional é autenticado automaticamente pelo sistema — não precisa fazer login manual em seguida. **Correção e ampliação da decisão (27/08/2026, mesmo dia):** a decisão inicial (acima) cobre o caso em que o profissional se cadastra por iniciativa própria, sem estímulo de nenhuma clínica — nesse caso, como não há vínculo nem convite, a sessão automática é direcionada para Meu Perfil (E4) com o banner informativo padrão (mesma regra de roteamento da RN-CIU-009, aplicada a um profissional com 0 vínculos ativos). Esse é, na versão atual da arquitetura de convite (revisão de 27/08/2026, mesmo dia, adiante), o único caminho possível pelo E2: uma pessoa convidada por uma clínica nunca chega a este wizard (ver RN-CIU-004 e a nota da Seção 1.2 de (CIU-E2)). Existe, porém, um segundo cenário, que não passa pelo E2: o profissional foi convidado por uma clínica antes de se cadastrar (o administrador já criou sua conta — Usuario + UsuarioCliente com Situacao = 'C' — ao registrar o convite, E3, RN-CIU-011). Nesse caso, o link do e-mail leva a uma tela própria do E3 — a tela de conclusão de cadastro (RN-CIU-012), se a senha ainda não foi definida, ou ao login normal do E1, se já foi (RN-CIU-023). Em ambos os casos, a autenticação (automática ao final da tela de conclusão de cadastro, ou manual pelo login) não vai direto para Meu Perfil nem para o cockpit — vai primeiro para a tela de aceite do vínculo (E3), pois existe um convite pendente (Situacao = 'C'). Somente depois de aceitar o vínculo, e com a verificação de Perfil de acesso associada, o profissional chega à sua tela inicial de fato. Ver o touchpoint "Profissional foi convidado por uma clínica", acima, e a Seção 4 de (CIU-E3) para o detalhamento completo. Esta decisão está registrada, em sua forma completa (as duas ramificações), como RN-CIU-022 (Seção 5). A forma como o segundo cenário é alcançado foi redesenhada nesta versão (v2.4): em vez de um convite "solto" pré-conta com pré-preenchimento no E2, o administrador cria a conta diretamente (E3, RN-CIU-011), e o E3 passou a ter sua própria tela de conclusão de cadastro (RN-CIU-012) e sua própria lógica de roteamento do link de convite (RN-CIU-023) — ver Histórico de Versões (Seção 11). --- ## 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). 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.4) **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: 1. **Se existe convite pendente** — o profissional é direcionado para a tela de aceite do vínculo (E3, RN-CIU-014), antes de qualquer outro destino. 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á). 2. **Se não existe 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 2, 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 (item 1) 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. **[PROPOSTA — extensão de consistência não descrita explicitamente pelo solicitante]** A aplicação da verificação de convite pendente também ao fluxo de login manual (E1) — e não apenas à autenticação automática do E2 ou da tela de conclusão de cadastro do E3 — é uma extensão lógica proposta por quem elaborou este documento: sem ela, um usuário já existente que recebe um convite de uma nova clínica nunca veria a tela de aceite ao fazer login normalmente. Esta extensão específica ao login (E1) permanece como proposta sinalizada para confirmação; o restante do mecanismo (E2 e a tela de conclusão de cadastro do E3) foi confirmado pelo solicitante ao longo da definição da arquitetura de convite (27/08/2026). 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 e da verificação de Perfil de acesso para onde este roteamento leva. --- ## 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|v1.9|Nenhuma (épico base)| |E2|Auto-cadastro Público|✅ Finalizado|v1.6|E1| |E3|Convite e Vínculo|✅ Finalizado (Definição + Especificação)|v2.0|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|⏳ A especificar|—|E1| ### 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| ### 7.3 Resumo dos épicos finalizados E1 — Núcleo de Identidade e Autenticação (v1.9): 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 em 27/08/2026 conforme o domínio C/V/B criado no E3). Mensagens multilíngues (pt-BR, en-US, es-419). 2 histórias de usuário, 19 critérios de aceitação, 6 fluxos de exceção, 4 endpoints, 4 tabelas. E2 — Auto-cadastro Público (v1.6): 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. 2 histórias de usuário, 22 critérios de aceitação, 6 fluxos de exceção, 4 endpoints, 4 tabelas. E3 — Convite e Vínculo (v2.0): 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, 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). Após o aceite, verifica Perfil de acesso associado: se existe, segue para o cockpit; se não existe, exibe mensagem orientando a aguardar ou contatar o administrador. Abandona a proposta de tabela nova `Convite` (v1.x) em favor de reaproveitar Usuario/UsuarioCliente com um domínio de situação (C/V/B) e duas novas colunas propostas em UsuarioCliente (token e prazo de validade do convite). 2 histórias de usuário, 13 critérios de aceitação, 7 fluxos de exceção, 6 endpoints, 4 tabelas existentes, nenhuma tabela nova. --- ## 8. Convenções de Documentação ### Estrutura de cada épico Cada épico segue a estrutura: 1. Visão Geral (o que inclui, dependências, paralelização) 2. Regras de Negócio (em linguagem de negócio, sem referências a campos de banco) 3. Histórias de Usuário 4. Descrição Funcional Detalhada (layout, comportamento, estados visuais, decisões de design, detalhes técnicos) 5. Critérios de Aceitação (formato Dado/Quando/Então) 6. Fluxos de Exceção (gatilho, comportamento, recuperação) 7. Validações de Campos (tabela) 8. Mapeamento de Componentes de Interface (tabela com tokens do Design System) 9. Integração com Backend (endpoints, mapeamento de tabelas) 10. Catálogo de Mensagens (multilíngue, com IDs) 11. Conformidade SBIS 12. Metadados do Épico Nota: esta estrutura por épico ainda não cobre a Seção 3 (Protótipo HTML) nem uma Seção 4 (Mapeamento de Banco de Dados) completa, previstas na metodologia Skill Designer — pendência registrada para quando os épicos E1 e E2 forem revisados. ### 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-XXX (numeração global entre épicos — o usuário renumera) - 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): nome da mãe, sexo, gênero, raça/cor, nacionalidade, naturalidade, endereço, documentos nacionais, passaporte, CNS — não existem na tabela Usuario atual. Propor criação de campos ou tabela complementar na Seção 4 do documento guarda-chuva. - Estrutura genérica de conselho (tipo, número, UF) e tipo de profissional — podem exigir novos campos ou tabela separada. - Tabelas de terminologia (tipos de conselho, tipos de profissional, especialidades, CBO) — verificar existência e estrutura no banco IpTerminologia. - **[PROPOSTA]** Domínio do campo `UsuarioCliente.Situacao` (IpSeguranca) — C (Convidado), V (Vinculado), B (Bloqueado); não documentado anteriormente em EsquemaGemed21.csv. Duas novas colunas propostas na mesma tabela, `TokenConvite` e `DataExpiracaoConvite`, nulas exceto enquanto Situacao = 'C'. Substitui a proposta de tabela nova `Convite` das versões anteriores deste documento (v2.2–v2.3) — ver Histórico de Versões. Detalhamento completo, com justificativa da modelagem, em (CIU-E3), Seção 9.2. --- ## 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 | 3 (E1 v1.9, E2 v1.6, E3 v2.0) | | Épicos pendentes | 2 (E4, E6) | | 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.4) | | Regras de negócio específicas de épico (referenciadas aqui) | 19 (RN-CIU-001, 002, 003, 004, 009, 010, 011, 012, 013, 014, 015, 016, 017, 018, 019, 020, 021, 023, 024) | | 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 + colunas de convite em UsuarioCliente [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.