CHECK-IN DE USUÁRIOS NO SISTEMA
Documento pai: Especificação Funcional de Software — Gemed Onco Versão: 2.2 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 dados que ela já informou | Convite disparado pelo administrador da clínica (E3); o link do e-mail leva ao auto-cadastro pré-preenchido (E2) se a pessoa ainda não tem conta, ou ao login (E1) se já tem; em ambos os casos, ao autenticar, a existência de convite pendente direciona para a tela de aceite do vínculo (E3) antes de qualquer outro destino (RN-CIU-022) | O pré-preenchimento de CPF/e-mail evita repetir dados que a clínica já forneceu ao criar o convite. O aceite é 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) cobria apenas 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 caso permanece correto e inalterado.
Existe, porém, um segundo cenário: o profissional foi convidado por uma clínica antes de se cadastrar (o administrador já cadastrou seu CPF e e-mail — E3). Nesse caso, a autenticação automática pós-cadastro (ou o login normal, se a pessoa já tinha conta) 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. 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 novo touchpoint “Profissional foi convidado por uma clínica”, acima, e a Seção 2 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) — reescrita nesta versão (v2.2) para cobrir ambos os cenários.
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)
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 (reescrita nesta versão para cobrir convite pendente): tanto após a autenticação automática do auto-cadastro (E2) quanto após um login manual (E1), o sistema verifica primeiro se existe um convite pendente (E3, RN-CIU-011) associado ao usuário:
- 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á).
- 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 típico de um profissional recém-cadastrado sem nenhum convite (auto-cadastro por iniciativa própria) recai no item 2, com 0 vínculos ativos — resultando no direcionamento a Meu Perfil, exatamente como descrito na decisão original da v2.1. O que muda nesta revisão é que esse não é mais o único caminho possível: um profissional convidado (item 1) 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 ao pós-cadastro (E2), é 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. O cenário descrito originalmente pelo solicitante cobria apenas o momento pós-auto-cadastro; a extensão ao login está sinalizada aqui para confirmação.
Usada por: (CIU-E2) — tela de sucesso do wizard, ao final da Etapa 3; (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 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.8 | Nenhuma (épico base) |
| E2 | Auto-cadastro Público | ✅ Finalizado | v1.5 | E1 |
| E3 | Convite e Vínculo | ✅ Finalizado (Definição + Especificação) | v1.0 | E1, E2 |
| 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 | Pré-preenchimento do auto-cadastro via 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 | Convite para CPF já cadastrado [PROPOSTA] | (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.8): 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 (RN-CIU-022) e direciona para a tela de aceite do vínculo (E3) quando aplicável. 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.5): 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, conforme convite pendente ou não, direciona para a tela de aceite do vínculo (E3) ou para Meu Perfil (RN-CIU-022). Quando acessado via link de convite, os campos CPF e e-mail vêm pré-preenchidos (E3). 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 (v1.0): Administrador da clínica pré-cadastra CPF + e-mail de um profissional, disparando um convite por e-mail. O link leva ao auto-cadastro pré-preenchido (E2, se a pessoa não tem conta) ou ao login (E1, se já tem). Ao autenticar, convite pendente direciona para a tela de aceite do vínculo — leitura das regras básicas e aceite explícito, que cria o vínculo (UsuarioCliente). 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. Introduz a proposta de tabela nova Convite (não existente no schema atual). 2 histórias de usuário, 12 critérios de aceitação, 6 fluxos de exceção, 5 endpoints, 4 tabelas existentes + 1 proposta.
8. Convenções de Documentação
Estrutura de cada épico
Cada épico segue a estrutura:
- Visão Geral (o que inclui, dependências, paralelização)
- Regras de Negócio (em linguagem de negócio, sem referências a campos de banco)
- Histórias de Usuário
- Descrição Funcional Detalhada (layout, comportamento, estados visuais, decisões de design, detalhes técnicos)
- Critérios de Aceitação (formato Dado/Quando/Então)
- Fluxos de Exceção (gatilho, comportamento, recuperação)
- Validações de Campos (tabela)
- Mapeamento de Componentes de Interface (tabela com tokens do Design System)
- Integração com Backend (endpoints, mapeamento de tabelas)
- Catálogo de Mensagens (multilíngue, com IDs)
- Conformidade SBIS
- 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] Tabela
Convite(IpSeguranca) — armazena CPF, e-mail, clínica, perfil pré-selecionado (opcional), token, status e prazo de validade de um convite antes do aceite. Não existe hoje em EsquemaGemed21.csv; necessária porque UsuarioCliente exige um UsuarioId já existente. Detalhamento completo 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.8, E2 v1.5, E3 v1.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) |
| 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, tabela Convite [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.