# CHECK-IN DE USUÁRIOS NO SISTEMA Documento pai: Especificação Funcional de Software — Gemed Onco Versão: 1.0 Data: 12/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 (a especificar — E3) - Vínculo entre usuário e clínica (a especificar — 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. Épicos |Épico|Título|Status|Versão|Dependências| |---|---|---|---|---| |E1|Núcleo de Identidade e Autenticação|✅ Finalizado|v1.5|Nenhuma (épico base)| |E2|Auto-cadastro Público|✅ Finalizado|v1.2|E1| |E3|Convite e Vínculo|⏳ A especificar|—|E1, E2| |E4|Meu Perfil|⏳ A especificar|—|E1, E2| |E6|Seleção de Clínica|⏳ A especificar|—|E1| ### 4.1 Resumo dos épicos finalizados E1 — Núcleo de Identidade e Autenticação (v1.5): 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. 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.2): 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. 2 histórias de usuário, 22 critérios de aceitação, 6 fluxos de exceção, 4 endpoints, 4 tabelas. --- ## 5. Regras de Negócio Transversais As regras abaixo se aplicam a todos os épicos do Check-in de Usuários. ### 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. ### Unicidade global do usuário O cadastro de usuário é global — existe uma única conta por pessoa no sistema, independentemente de quantas clínicas ela esteja vinculada. O usuário não se cadastra novamente para cada clínica; ele se cadastra uma vez e recebe vínculos conforme é convidado. ### Documento único como chave de identificação O usuário é identificado de forma unívoca pelo seu documento único. No Brasil, o CPF é a chave de identificação. Em outros países, o sistema deve adaptar para o documento local equivalente. O documento é exclusivo — não pode pertencer a dois usuários ativos diferentes. ### Anti-enumeração no login No fluxo de login, o sistema não aplica máscara, validação de formato nem restrição de entrada no campo de documento. O campo aceita qualquer texto livre. A única resposta para qualquer falha de login é a mensagem genérica "Usuário ou senha inválidos." — sem distinguir se o problema foi documento não encontrado, formato inválido, senha incorreta ou usuário excluído. ### Parametrização via UsuarioSenhaParametros Os seguintes parâmetros são parametrizáveis via tabela UsuarioSenhaParametros (IpSeguranca): |Parâmetro|Descrição|Valor atual| |---|---|---| |QuantidadeTentativas|Máximo de tentativas falhas antes do bloqueio|5| |MinutosBloqueado|Duração do bloqueio temporário (minutos)|15| |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| ### Estrutura genérica de conselho profissional O sistema utiliza uma estrutura genérica para registro de conselho profissional: tipo de conselho (CRM, COREN, CRF, CRFA, CRN, CRO, CRP, etc.), número de registro e UF. O conselho é obrigatório para todo profissional de saúde que assina prontuário. Usuários que não assinam prontuário não precisam informar conselho. ### Suporte multilíngue O sistema suporta três idiomas: pt-BR (português do Brasil), en-US (inglês) e es-419 (espanhol latinoamericano). 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. ### 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. ### Máscara de celular parametrizada por país A máscara de celular é parametrizada por país. No Brasil, utiliza o formato (00) 00000-0000. Quando o sistema operar em outros países, a máscara deve ser adaptada conforme o padrão telefônico local. ### Documentos condicionais por nacionalidade A seção de documentos é condicional conforme a nacionalidade selecionada: - Brasileira ou Naturalizado: exibe documentos nacionais (identidade, CNS) - Estrangeiro: exibe documentos de estrangeiro (passaporte, CNS) Preparado para internacionalização futura — a seção de documentos nacionais deve ser adaptada para exibir os documentos específicos do país de operação (SSN, DNI, CURP, etc.). --- ## 6. 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 ### 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. --- ## 7. 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| |UsuarioSenhaHistorico|IpSeguranca|E1, E2| |UsuarioSenhaParametros|IpSeguranca|E1, E2| |UsuarioCliente|IpSeguranca|E1, E2| ### 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. --- ## 8. Conformidade SBIS — Visão Geral |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| --- ## 9. Metadados | Atributo | Valor | | ------------------------------ | ------------------------------------------------------------ | | Funcionalidade pai | Check-in de Usuários no Sistema | | Épicos finalizados | 2 (E1 v1.5, E2 v1.2) | | Épicos pendentes | 3 (E3, E4, E6) | | Regras de negócio transversais | 9 | | Requisitos SBIS aplicáveis | 12 | | Bancos utilizados | 2 (IpSeguranca, IpTerminologia) | | Tabelas existentes utilizadas | 4 | | Pendências de BD | 3 grupos (dados avançados, conselho genérico, terminologias) | | Idiomas suportados | 3 (pt-BR, en-US, es-419) |