Especificação da funcionalidade: cadastro profissional, validação e escopo por CRP¶

Branch da funcionalidade: Não criada — especificação em elaboração

Criado em: 2026-08-11

Status: Rascunho — aguardando revisão do responsável pelo produto

Entrada: Cadastro profissional com CPF e/ou CNPJ, validação e revalidação de registros CRP em produção, suporte a múltiplos CRPs, visualização filtrada por CRP ou por todos os registros, cota de pacientes por profissional e bloqueio de ações enquanto o cadastro estiver incompleto.

Objetivo do produto¶

Permitir que cada profissional mantenha uma única conta, cadastre CPF e CNPJ quando aplicável, associe e revalide um ou mais registros CRP legítimos e visualize sua operação por um CRP específico ou de forma consolidada em “Todos”. O CRP funciona como escopo operacional e de emissão futura, sem multiplicar assinatura, cota ou identidade do usuário. Ao mesmo tempo, o produto deve conduzir novos usuários à conclusão do cadastro e impedir operações que exigem habilitação profissional enquanto houver pendências.

Escopo¶

Dentro do escopo¶

Cadastro profissional que admite CPF, CNPJ ou ambos na mesma conta, com pelo menos um documento fiscal válido.
Descoberta e associação de um ou mais CRPs a partir de cada documento informado.
Vínculo explícito de cada CRP ao CPF ou ao CNPJ que originou/justifica aquele registro.
Validação externa de CRP em produção e validação local sem dependência externa.
Revalidação posterior e estado visível de validade de cada CRP.
Habilitação provisória por até cinco dias quando a validação externa não puder ser concluída, com novas tentativas e bloqueio ao fim do prazo.
Garantia de unicidade de identidade e de associação de registros.
Filtro de escopo junto ao avatar na barra lateral, com cada CRP e a opção “Todos”.
Atribuição das entidades que necessitam de contexto profissional a um CRP, preservando visão consolidada da conta.
Cota de pacientes calculada por profissional/conta, sem multiplicação por CRP.
Estado reutilizável de habilitação do usuário, com bloqueio centralizado de ações de criação enquanto o cadastro estiver incompleto.
Fundação de tiers com identificadores iniciais free e standard, mantendo regras de plano separadas das regras cadastrais e profissionais.
Orientação clara para concluir o cadastro sem impedir navegação, consulta de ajuda ou encerramento da sessão.

Fora do escopo¶

Compartilhamento de um contexto CRP entre vários usuários ou equipes de clínica.
Transferência automática de vínculos ou documentos entre CRPs.
Faturamento, planos distintos ou assinaturas distintas por CRP.
Definição de preços, cobrança e catálogo completo de benefícios dos tiers.
Alteração da fonte oficial ou administração do serviço externo de consulta.
Migração automática de entidades existentes entre CRPs sem uma decisão posterior de migração.

Cenários de usuário e testes (obrigatório)¶

História de usuário 1 - Concluir cadastro e habilitar a conta (Prioridade: P1)¶

Após criar a conta, o profissional é direcionado à área de cadastro profissional. Ele informa pelo menos um documento fiscal e pode manter CPF e CNPJ simultaneamente. Para cada CRP encontrado ou informado, confirma se o vínculo pertence ao CPF ou ao CNPJ cadastrado. Ao concluir os requisitos, a conta passa a permitir ações operacionais.

Motivo da prioridade: A identidade profissional e o CRP são pré-condições para segurança, isolamento dos dados e uso clínico do produto.

Teste independente: Criar uma conta nova, concluir o cadastro com uma identidade e um CRP válidos e confirmar que a primeira ação de criação passa de bloqueada para permitida.

Cenários de aceitação:

Dado uma conta recém-criada sem cadastro profissional completo, Quando o usuário entra no produto, Então ele é direcionado à etapa de cadastro profissional com indicação dos itens pendentes.
Dado um cadastro incompleto, Quando o usuário navega para outra área, Então ele pode visualizar a área permitida, mas toda ação de criação protegida permanece bloqueada e apresenta uma mensagem com link para concluir o cadastro.
Dado todos os campos obrigatórios preenchidos e pelo menos um CRP aceito conforme as regras do ambiente, Quando o usuário salva o cadastro, Então sua conta fica habilitada e o escopo inicial passa a ser “Todos”.
Dado CPF e CNPJ válidos, Quando o usuário salva o cadastro, Então ambos permanecem vinculados ao mesmo perfil profissional.
Dado um documento com formato inválido, Quando o usuário tenta prosseguir, Então o produto recusa somente esse documento e informa como corrigi-lo sem criar associações de CRP.

História de usuário 2 - Descobrir e validar múltiplos CRPs (Prioridade: P1)¶

O profissional consulta por CPF e/ou CNPJ e visualiza os registros compatíveis retornados pela fonte, podendo confirmar quais pertencem à sua atuação e a qual documento cada CRP está ligado.

Motivo da prioridade: A busca por identidade evita que o usuário precise conhecer previamente todos os registros e permite representar profissionais registrados em mais de um conselho regional.

Teste independente: Consultar uma identidade de teste associada a dois CRPs e confirmar que ambos são apresentados, normalizados e podem ser associados sem duplicação.

Cenários de aceitação:

Dado CPF e CNPJ cadastrados, Quando as consultas são concluídas, Então os registros retornados por ambos são apresentados separadamente com região, número, tipo, situação e documento de vínculo.
Dado variações de máscara, espaços ou pontuação do mesmo CRP, Quando são informadas ou retornadas, Então o produto as reconhece como um único registro normalizado.
Dado o ambiente de produção, Quando um CRP é associado, Então a validade e a situação do registro são verificadas na fonte externa antes de habilitá-lo.
Dado um ambiente local ou de teste, Quando um CRP estruturalmente válido é associado, Então o fluxo funciona sem chamada à fonte externa e o registro fica explicitamente marcado como não verificado externamente.
Dado um CRP inválido, inexistente, cancelado ou incompatível com o documento escolhido, Quando o usuário tenta associá-lo em produção, Então o registro não habilita operações profissionais e o motivo é informado de forma segura.
Dado um CRP vinculado ao CPF, Quando dados para uma declaração futura forem preparados, Então o produto consegue identificar que aquele registro deve usar a identidade PF e não o CNPJ do mesmo perfil.

História de usuário 3 - Filtrar a operação por CRP ou visualizar todos (Prioridade: P1)¶

Um profissional com mais de um CRP pode escolher rapidamente um registro no seletor junto ao avatar para filtrar listas, contagens e buscas. Também pode selecionar “Todos” para trabalhar com a visão consolidada da própria conta.

Motivo da prioridade: O filtro organiza a atuação por conselho regional sem obrigar o profissional a alternar entre ambientes rígidos nem perder a visão consolidada.

Teste independente: Associar dados aos CRPs A e B, selecionar cada filtro e depois “Todos”, confirmando que os resultados correspondem respectivamente a A, B e à união autorizada dos dois.

Cenários de aceitação:

Dado um profissional com dois ou mais CRPs habilitados, Quando ele abre o seletor junto ao avatar, Então vê “Todos”, seus registros e identifica claramente o filtro atual.
Dado um profissional com exatamente um CRP, Quando visualiza a sidebar, Então vê apenas a identificação desse CRP, sem seletor e sem a opção “Todos”.
Dado o CRP A selecionado, Quando o usuário lista, busca ou conta entidades sensíveis ao CRP, Então somente dados atribuídos ao CRP A são apresentados.
Dado “Todos” selecionado, Quando o usuário lista, busca ou conta entidades, Então recebe a visão consolidada de todos os CRPs pertencentes à própria conta.
Dado um CRP específico selecionado, Quando o usuário abre a criação de paciente, Então esse CRP já aparece selecionado e pode ser alterado para outro registro habilitado.
Dado “Todos” selecionado com múltiplos CRPs, Quando o usuário inicia uma criação que exige CRP, Então o produto solicita a escolha explícita do CRP antes de concluir a operação.
Dado uma troca de filtro, Quando ela é concluída, Então telas e contagens subsequentes refletem o novo filtro sem reutilizar resultados incompatíveis do filtro anterior.

História de usuário 4 - Aplicar a cota por profissional (Prioridade: P2)¶

O profissional visualiza e consome uma única cota de pacientes, independentemente da quantidade de CRPs associados.

Motivo da prioridade: A regra comercial de cinco pacientes no plano gratuito pertence ao profissional e não deve ser multiplicada pela criação de contextos CRP.

Teste independente: Distribuir cinco pacientes ativos entre dois CRPs de uma conta gratuita e confirmar que a criação ou reativação do sexto é recusada em qualquer contexto.

Cenários de aceitação:

Dado uma conta gratuita com cinco pacientes ativos somados entre todos os CRPs, Quando o usuário tenta criar ou reativar outro paciente, Então a operação é bloqueada com explicação da cota da conta.
Dado uma conta abaixo da cota, Quando um paciente é criado em um CRP, Então o consumo atualizado é refletido para o mesmo profissional em todos os contextos.
Dado um novo CRP associado, Quando ele se torna ativo, Então a cota do profissional não é reiniciada nem multiplicada.

História de usuário 5 - Evoluir bloqueios por requisito de habilitação (Prioridade: P2)¶

O produto pode acrescentar futuramente novos requisitos obrigatórios sem espalhar regras divergentes por cada tela. O usuário recebe um estado único de habilitação, a lista de pendências e uma ação recomendada.

Motivo da prioridade: O cadastro profissional é o primeiro requisito, mas o mesmo mecanismo deverá suportar consentimentos, contratos, situação de assinatura ou novas exigências regulatórias.

Teste independente: Simular uma conta com uma pendência de cadastro e verificar que diferentes ações protegidas recebem a mesma decisão, motivo e destino para resolução.

Cenários de aceitação:

Dado uma conta com uma ou mais pendências, Quando qualquer ação protegida é solicitada, Então a decisão de bloqueio identifica todas as pendências relevantes e indica onde resolvê-las.
Dado uma ação não protegida, Quando a conta possui pendências, Então a ação continua disponível.
Dado que a última pendência foi resolvida, Quando o estado de habilitação é reavaliado, Então todas as ações correspondentes são liberadas sem intervenção administrativa.

História de usuário 6 - Revalidar o estado dos CRPs (Prioridade: P1)¶

O produto verifica novamente CRPs já associados e torna visível quando a situação externa foi confirmada, alterada ou não pôde ser consultada.

Motivo da prioridade: Um registro válido no cadastro pode mudar de situação; a plataforma precisa representar o estado atual sem apagar o histórico ou os vínculos existentes.

Teste independente: Revalidar um CRP cuja situação externa foi alterada e confirmar que o novo estado, a data da consulta e as restrições correspondentes aparecem sem perda de dados.

Cenários de aceitação:

Dado um CRP previamente validado, Quando uma revalidação bem-sucedida retorna a mesma situação, Então o momento da última confirmação é atualizado.
Dado um CRP previamente habilitado, Quando a fonte retorna uma situação que não permite exercício, Então o CRP fica visivelmente restrito e novas operações vinculadas a ele são bloqueadas sem excluir dados históricos.
Dado uma tentativa de revalidação indisponível, Quando a consulta falha, Então o último estado confirmado é preservado separadamente do erro e da tentativa atual.
Dado um novo CRP cuja fonte externa está indisponível, Quando os demais dados são válidos, Então ele fica provisoriamente habilitado, recebe prazo de cinco dias e entra no fluxo de novas tentativas.
Dado um CRP provisório ainda sem confirmação externa, Quando completa cinco dias desde sua associação, Então ele passa a bloquear novas operações profissionais dependentes até uma validação bem-sucedida.
Dado um CRP provisório, Quando uma tentativa posterior confirma sua validade dentro ou depois da janela, Então ele passa ao estado validado e o bloqueio correspondente é removido.

História de usuário 7 - Entender todos os bloqueios de uma operação (Prioridade: P1)¶

Antes de executar uma ação, o profissional recebe uma decisão coerente que considera cadastro, CRP e limites do seu tier sem reduzir tudo a um único status genérico.

Motivo da prioridade: Uma mesma conta pode estar apta em uma dimensão e bloqueada em outra; motivos diferentes exigem mensagens e caminhos de resolução diferentes.

Teste independente: Simular uma conta free no limite de pacientes e com CRP restrito, tentar criar um paciente e confirmar que a decisão contém os dois motivos, cada um com sua ação de resolução.

Cenários de aceitação:

Dado um usuário free com cinco pacientes ativos e CRP válido, Quando tenta cadastrar o sexto paciente, Então recebe bloqueio de limite do plano sem mensagem de problema cadastral ou profissional.
Dado um usuário abaixo do limite, mas com CRP inativo ou provisório expirado, Quando tenta cadastrar um paciente nesse CRP, Então recebe bloqueio profissional sem mensagem de limite atingido.
Dado mais de uma regra impeditiva aplicável, Quando a operação é avaliada, Então todos os motivos relevantes são retornados de forma estruturada e ordenada.
Dado que uma pendência é resolvida, Quando a operação é reavaliada, Então somente aquele motivo desaparece e as demais regras continuam sendo aplicadas.

Casos limítrofes¶

A consulta não encontra CRP para o CPF/CNPJ informado.
A consulta retorna registros duplicados, com máscaras diferentes ou dados parciais.
Um mesmo resultado inclui registros ativos e inativos.
O serviço externo demora, fica indisponível, retorna erro ou responde em formato inesperado.
Um CRP previamente válido muda de situação após ter dados clínicos associados.
O usuário remove, perde ou deixa inativo o CRP atualmente selecionado.
Uma sessão é aberta simultaneamente em duas abas e o CRP ativo muda em apenas uma delas.
Um identificador direto de entidade de outro CRP é reutilizado em URL ou requisição.
Duas tentativas concorrentes procuram associar a mesma identidade ou o mesmo CRP.
O usuário atinge a cota por duas criações ou reativações simultâneas sob filtros diferentes.
Um usuário antigo possui dados, mas não possui CRP que permita determinar o contexto de origem.
O usuário está em “Todos” e inicia uma operação cuja emissão futura depende de CPF ou CNPJ.
Um paciente precisa mudar sua atribuição de um CRP para outro sem perder histórico.
O prazo de cinco dias termina enquanto o serviço externo continua indisponível.
Uma tentativa futura é executada mais de uma vez ou fora de ordem.
O usuário muda de tier enquanto possui operações bloqueadas por outro motivo.

Requisitos (obrigatório)¶

Requisitos funcionais¶

FR-001: O produto MUST manter a conta, os documentos fiscais, os registros profissionais e o filtro operacional como conceitos distintos.
FR-002: O cadastro MUST aceitar CPF, CNPJ ou ambos no mesmo perfil, exigindo pelo menos um documento fiscal válido e normalizado.
FR-003: CPF e CNPJ MUST possuir verificações de unicidade independentes após normalização; quando um documento já pertencer a outra conta, a nova associação MUST ser bloqueada e o usuário MUST ser direcionado à recuperação da conta existente sem exposição de dados dessa conta.
FR-004: O produto MUST consultar registros separadamente por cada CPF/CNPJ cadastrado e aceitar uma coleção de zero, um ou vários CRPs como resultado de cada documento.
FR-005: Cada CRP MUST ser armazenado em formato canônico que preserve região e número, independentemente da máscara informada.
FR-006: Cada associação de CRP MUST indicar exatamente um documento de vínculo pertencente ao mesmo perfil: CPF ou CNPJ.
FR-007: Um mesmo CRP canônico e documento de vínculo MUST NOT ser associado mais de uma vez e MUST NOT habilitar contas conflitantes sem resolução segura de titularidade.
FR-008: Em produção, um CRP MUST ser validado na fonte externa antes de se tornar habilitado, registrando resultado, situação informada, documento consultado e momento da verificação.
FR-009: Em ambiente local ou de teste, o fluxo MUST NOT depender da fonte externa; ainda assim, MUST validar formato, região, documento de vínculo e unicidade e MUST distinguir o resultado local de uma validação oficial.
FR-010: Quando a fonte externa estiver indisponível em produção, um CRP com formato, documento de vínculo e unicidade válidos MUST poder ficar provisoriamente habilitado por cinco dias corridos a partir da associação.
FR-011: O produto MUST apresentar mensagens acionáveis para documento sem resultados, registro incompatível, situação inválida, conflito de unicidade, indisponibilidade e erro de validação.
FR-012: O produto MUST permitir múltiplos CRPs habilitados por profissional, inclusive quando parte estiver vinculada ao CPF e parte ao CNPJ do mesmo perfil.
FR-013: O produto MUST oferecer um filtro operacional com a opção “Todos” e cada CRP habilitado pertencente à conta.
FR-014: Na ausência de um filtro CRP informado, o produto MUST assumir “Todos”, sempre limitado aos dados pertencentes ao usuário autenticado.
FR-015: O seletor MUST ficar junto ao avatar na barra lateral, mostrar região/número, documento de vínculo e situação de validação.
FR-015A: O seletor e a opção “Todos” MUST aparecer somente quando houver dois ou mais CRPs; com exatamente um CRP, a sidebar MUST exibir o registro como identificação não interativa e o produto MUST usá-lo implicitamente.
FR-016: Cada paciente MUST possuir exatamente um CRP de atribuição; entidades dependentes podem derivar esse CRP pelo relacionamento com o paciente quando isso for inequívoco.
FR-017: Toda listagem, busca e contagem sensível ao CRP MUST aplicar o CRP selecionado como filtro quando específico e MUST abranger todos os CRPs da conta quando “Todos” estiver selecionado.
FR-018: A seleção de CRP MUST NOT substituir a autorização por proprietário; nenhum filtro informado pelo cliente pode ampliar o acesso para outra conta.
FR-019: Uma operação de criação que exige atribuição profissional MUST usar o CRP selecionado quando específico e MUST exigir escolha explícita quando o filtro for “Todos”.
FR-019A: Na criação de paciente, o campo CRP MUST iniciar com o filtro atual pré-selecionado, permanecer alterável quando houver outros CRPs e ser apenas informativo quando existir um único registro.
FR-020: Ao trocar o filtro, o produto MUST invalidar ou separar qualquer estado que possa apresentar resultados incompatíveis do filtro anterior.
FR-021: A cota de pacientes ativos MUST pertencer à conta profissional e MUST NOT ser multiplicada pela quantidade de CRPs.
FR-022: A verificação de cota MUST ser segura contra criações e reativações simultâneas realizadas sob filtros CRP diferentes.
FR-023: A cota MUST contar os pacientes ativos da conta inteira, independentemente do CRP atribuído; atribuir ou trocar o CRP de um paciente existente MUST NOT criar uma nova vaga nem reiniciar o consumo.
FR-024: Após criar a conta, o novo profissional MUST ser direcionado para uma área autenticada de cadastro profissional completo.
FR-025: A conclusão inicial MUST exigir, no mínimo, telefone, endereço, ao menos um CPF/CNPJ e um CRP habilitado e vinculado ao documento correspondente conforme as regras do ambiente.
FR-026: O usuário com cadastro incompleto MUST poder navegar por áreas seguras, acessar configurações, ajuda e encerramento de sessão, mas MUST ser impedido de executar ações de criação protegidas.
FR-027: Cada bloqueio MUST informar que o cadastro está incompleto, listar a pendência relevante e oferecer uma ação direta para resolvê-la.
FR-027A: Pendências globais da conta MUST aparecer de forma compacta e integrada à sidebar; elas MUST NOT ocupar uma faixa permanente sobre o conteúdo principal.
FR-027B: Toda mensagem, título e ação apresentada ao usuário MUST estar em pt-BR; códigos técnicos podem permanecer em inglês apenas internamente.
FR-027C: A ação “Novo paciente” MUST permanecer desabilitada enquanto cadastro, CRP ou tier impedirem a criação, e a sidebar MUST explicar os bloqueios e seus caminhos de resolução.
FR-028: O bloqueio MUST ser aplicado na autorização da operação, além da interface, de modo que chamadas diretas não o contornem.
FR-029: O estado de habilitação MUST ser uma avaliação única e extensível, composta por requisitos identificáveis, seus estados e destinos de resolução, para admitir novas exigências futuras.
FR-030: Alterações de documentos, associação, validação, revalidação, situação ou filtro CRP e decisões de bloqueio MUST gerar histórico auditável sem registrar dados clínicos ou respostas externas desnecessárias.
FR-031: O produto MUST revalidar CRPs já associados segundo eventos e periodicidade definidos no planejamento, preservando separadamente último estado confirmado, última tentativa e eventual falha.
FR-032: Uma mudança posterior de situação do CRP MUST preservar os dados existentes e bloquear novas operações incompatíveis vinculadas àquele CRP até resolução, sem apagar ou mover automaticamente registros.
FR-033: A visão “Todos” MUST continuar disponível para dados históricos autorizados mesmo quando um dos CRPs estiver restrito, deixando a situação desse vínculo visível.
FR-034: O produto MUST definir uma migração revisável para usuários e entidades existentes, permitindo que dados sem atribuição CRP continuem visíveis em “Todos” até serem classificados, sem atribuição silenciosa ao registro errado.
FR-035: Dados trazidos pela consulta externa MUST ser apresentados para confirmação quando puderem alterar documento, vínculo ou cadastro; a fonte externa MUST NOT sobrescrever silenciosamente dados já confirmados.
FR-036: Todo CRP provisório MUST gerar tentativas futuras de validação que possam ser repetidas com segurança sem duplicar vínculo, prazo, transição ou evento de auditoria.
FR-037: Se nenhuma tentativa confirmar o CRP até o fim do quinto dia corrido, o registro MUST passar automaticamente a um estado restrito e MUST bloquear novas operações profissionais que dependam dele.
FR-038: Uma validação bem-sucedida posterior ao bloqueio MUST atualizar o estado confirmado e liberar somente os impedimentos causados pela falta de validação daquele CRP.
FR-039: O produto MUST manter, para cada CRP, estados distinguíveis de validação: pendente de primeira tentativa, provisório, validado, inválido/inativo, restrito por prazo expirado e erro temporário de revalidação.
FR-040: A conta MUST possuir exatamente um tier vigente; os identificadores iniciais reconhecidos MUST ser free e standard, permitindo inclusão futura de outros tiers sem alterar as regras cadastrais ou de CRP.
FR-041: O tier free MUST limitar a conta a cinco pacientes ativos; o tier standard MUST existir como tier reconhecido, mas seus preços e demais limites serão definidos em uma especificação própria antes da oferta comercial.
FR-042: O produto MUST avaliar permissões por ação a partir de dimensões independentes: habilitação cadastral, situação do CRP aplicável, tier/limites da conta e outras políticas futuras.
FR-043: Uma decisão de operação MUST poder conter zero, um ou vários motivos de bloqueio identificáveis, cada um com origem, código estável, mensagem segura e destino de resolução quando houver.
FR-044: Resolver um motivo de bloqueio MUST NOT ignorar ou limpar automaticamente bloqueios originados por outras dimensões.
FR-045: A interface e as chamadas diretas MUST receber decisões equivalentes para a mesma conta, ação, CRP e estado de consumo.

Regras de negócio¶

BR-001: A unidade de assinatura e de cota é a conta profissional, não o CRP.
BR-002: O CRP é uma dimensão de atribuição e filtro dentro da conta; “Todos” representa a visão consolidada autorizada.
BR-003: Um CRP não cria uma nova conta, login, assinatura ou cota.
BR-004: No plano gratuito, o limite padrão é de cinco pacientes ativos na conta, somando todos os CRPs.
BR-005: Validação externa é obrigatória em produção e dispensada localmente; dispensa local não equivale a confirmação oficial.
BR-006: Alterar o filtro nunca transfere, reatribui ou duplica dados.
BR-007: O vínculo CRP → CPF/CNPJ deve permanecer disponível para documentos, declarações e emissões futuras.
BR-008: A janela provisória de CRP dura cinco dias corridos e não é renovada por novas falhas, novas sessões ou repetição da mesma associação.
BR-009: Cadastro, CRP e plano não formam um único status; são fontes independentes de regras para decisões sobre ações.
BR-010: free e standard pertencem à conta do usuário, nunca ao CRP.

Dimensões independentes de estado¶

Dimension	Initial States	Example Effect
Cadastro	incompleto, completo	Cadastro incompleto bloqueia ações protegidas e direciona para a área de conclusão.
CRP	pendente, provisório, validado, inválido/inativo, restrito por prazo, erro temporário	O estado do CRP decide se operações profissionais podem usar aquele registro.
Tier	`free`, `standard`	`free` bloqueia a criação/reativação acima de cinco pacientes ativos; capacidades do `standard` serão especificadas separadamente.
Consumo	abaixo do limite, no limite	O consumo é calculado para a conta inteira e participa da decisão da ação.

Essas dimensões não se substituem. A permissão final é calculada para cada ação e pode apresentar múltiplos bloqueios simultâneos.

Entidades principais¶

Conta de usuário: Credencial e identidade de acesso; é proprietária do plano e da cota.
Perfil profissional: Dados completos do profissional, podendo conter simultaneamente CPF e CNPJ, além de contato, endereço e estado de conclusão.
Documento fiscal: CPF ou CNPJ normalizado pertencente ao perfil e usado para descoberta, validação e futura emissão.
Registro profissional: CRP canônico associado ao perfil e a exatamente um documento fiscal; contém região, número, tipo, situação, origem e evidências mínimas de validação e revalidação.
Atribuição CRP: Referência de um paciente ou outra entidade-raiz a exatamente um CRP do proprietário, usada para filtragem e emissão futura.
Filtro CRP: Seleção de “Todos” ou de um CRP específico, sem alterar a fronteira de autorização da conta.
Requisito de habilitação: Regra identificável que informa estado, motivo de pendência, ações bloqueadas e destino de resolução.
Tier da conta: Identificador da categoria vigente da conta, inicialmente free ou standard, sem vínculo com um CRP específico.
Regra de capacidade: Política que decide se uma ação é permitida considerando uma dimensão, como cadastro, CRP ou tier.
Decisão de operação: Resultado agregado para uma ação, contendo permissão e todos os motivos de bloqueio aplicáveis.
Plano/cota profissional: Limites pertencentes à conta e consumo agregado entre filtros CRP.
Tentativa futura de validação: Trabalho rastreável para consultar novamente um CRP provisório, com agendamento, tentativas, resultado e execução segura contra repetição.
Entidade filtrável: Paciente ou recurso operacional/clínico que pertence à conta e possui atribuição CRP própria ou derivável.
Evento de auditoria: Registro seguro de alterações e decisões relevantes de identidade, CRP, contexto e habilitação.

Contrato externo e expectativas de falha¶

A dependência de consulta é a CRP Info API v2.0.0, descrita como serviço de verificação de CRP/CPF/CNPJ com cache e integração ao CFP.
A consulta suporta filtros por crp, cpf, cnpj, nome, regiao, tipo e atualização forçada; o produto usará identidade e, quando necessário, confirmação por CRP.
O contrato publicado não descreve formalmente o corpo de sucesso. O planejamento MUST capturar respostas reais controladas, definir um contrato interno estável e tratar qualquer campo externo como não confiável até validação.
A dependência já demonstrou poder responder com erro interno durante a elaboração desta especificação; timeout, erro de transporte, erro de servidor, resposta parcial e mudança de formato são fluxos obrigatórios, não exceções improváveis.
CPF, CNPJ e dados retornados pela fonte não devem aparecer em logs de diagnóstico em formato integral.

Critérios de sucesso (obrigatório)¶

Resultados mensuráveis¶

SC-001: Pelo menos 90% dos novos profissionais com dados válidos concluem o cadastro na primeira tentativa em até 5 minutos, excluindo períodos de indisponibilidade externa.
SC-002: Em 100% dos testes, selecionar um CRP limita corretamente os resultados e selecionar “Todos” retorna a união autorizada da conta sem duplicações.
SC-003: Em 100% dos testes com múltiplos CRPs, a troca de filtro atualiza listas e contagens sem exibir resultados incompatíveis do filtro anterior.
SC-004: Em 100% dos testes de concorrência na conta gratuita, a quantidade total de pacientes ativos nunca ultrapassa cinco, mesmo com operações simultâneas sob filtros diferentes.
SC-005: Em 100% dos ambientes locais de desenvolvimento, o cadastro e os testes do fluxo podem ser concluídos sem conexão com o serviço externo.
SC-006: Em 100% das ações protegidas testadas, uma conta incompleta recebe o mesmo conjunto coerente de pendências e um caminho direto para resolução.
SC-007: Nenhum documento fiscal ou vínculo CRP duplicado é criado em tentativas repetidas ou simultâneas com os mesmos valores normalizados.
SC-008: Falhas do serviço externo não causam perda de dados preenchidos pelo usuário e sempre resultam em estado compreensível e recuperável.
SC-009: Todos os dados migrados permanecem visíveis em “Todos”; os que não puderem ser atribuídos com segurança ficam explicitamente sinalizados e nenhum recebe CRP por suposição.
SC-010: Em 100% das revalidações, o produto distingue o último estado confirmado do resultado da tentativa mais recente, inclusive em falhas externas.
SC-011: Em 100% dos cenários com CRP provisório, operações permanecem disponíveis durante a janela e são bloqueadas imediatamente após completar cinco dias sem confirmação.
SC-012: Tentativas futuras repetidas, concorrentes ou fora de ordem não renovam o prazo nem produzem transições duplicadas.
SC-013: Em 100% dos testes com múltiplos impedimentos, a decisão apresenta cada motivo correto e a resolução de um deles não libera a ação enquanto outro permanecer.
SC-014: Em 100% dos testes de cota free, o sexto paciente ativo é bloqueado independentemente do filtro CRP selecionado.

Premissas¶

A primeira versão atende profissionais individuais, ainda que possam faturar como pessoa jurídica; equipes e acesso compartilhado continuam fora de escopo.
CPF e CNPJ são documentos independentes de descoberta e deduplicação, ambos podendo pertencer ao mesmo perfil; o e-mail continua sendo a credencial da conta.
Apenas novos usuários entram imediatamente no bloqueio de onboarding; usuários existentes dependem do plano de migração e rollout definido antes da ativação global.
Um CRP cuja situação deixe de permitir exercício não perde os dados históricos, mas deixa de aceitar novas operações clínicas até regularização ou decisão administrativa.
“Todos” é o filtro padrão quando nenhuma preferência ou indicação de CRP estiver disponível.
Leitura de páginas institucionais sem dados clínicos, configurações, ajuda e logout são consideradas ações seguras durante cadastro incompleto.
A lista final de entidades filtráveis será inventariada no planejamento; quando uma atribuição puder ser derivada com segurança de uma entidade raiz, não será necessário duplicá-la em todas as estruturas.
O intervalo e os eventos que disparam revalidação serão definidos no planejamento, mas a capacidade de revalidar e representar seus estados pertence a esta entrega.
O prazo de cinco dias começa na primeira associação provisória daquele vínculo CRP-documento e não é prorrogado por falhas subsequentes.
Inicialmente toda conta recebe um tier reconhecido; free possui a regra de cinco pacientes e standard fica reservado no modelo, sem oferta comercial ou benefícios adicionais até aprovação de uma especificação de planos.
Uma especificação separada tratará preços, cobrança, upgrades, downgrades, período de carência comercial e catálogo de capacidades por tier.

Dependências¶

Disponibilidade e contrato do serviço CRP Info em produção.
Definição de credenciais, limites de uso, observabilidade e política de dados para a integração.
Mecanismo confiável para executar e acompanhar tarefas futuras de validação sem perder trabalhos em reinicializações ou implantações.
Inventário das entidades que precisam ser filtráveis e das que podem derivar seu CRP por relacionamento.
Estratégia aprovada para atribuir CRP a dados existentes quando possível e manter os demais em “Todos” enquanto pendentes.

Riscos¶

Header tratado como autorização: mitigado mantendo a propriedade da conta como fronteira obrigatória; o CRP enviado pelo cliente apenas reduz o conjunto autorizado.
Associação indevida de CRP: mitigada por validação de identidade, unicidade, confirmação do usuário e auditoria.
Indisponibilidade externa bloquear cadastro: depende da decisão pendente sobre modo degradado.
Multiplicação indevida da cota: mitigada por cota no nível da conta e controle concorrente agregado.
Migração ambígua: dados continuam acessíveis em “Todos”, mas nenhuma atribuição CRP deve ser inventada quando houver mais de uma possibilidade.
Filtragem inconsistente: endpoints, caches, trabalhos em segundo plano, exportações e integrações podem divergir se não utilizarem a mesma regra reutilizável.
Fila indisponível ou atrasada: o vencimento do prazo deve ser determinado pela data persistida, não apenas pela execução pontual de uma tarefa.
Status único e ambíguo: mitigado por dimensões independentes e decisão agregada por ação.

Expectativas de ativação e verificação¶

A ativação em produção deve ocorrer somente após inventário das entidades filtráveis, migração compatível com “Todos”, testes de escopo e definição do modo degradado da validação externa.
O recurso deve permitir ativação controlada para contas novas antes de alcançar contas existentes.
A verificação deve incluir zero, um e vários CRPs; CPF e CNPJ simultâneos; vínculos distintos por documento; “Todos”; filtro específico; CRP inválido/inativo; revalidação; indisponibilidade externa; cota concorrente; e cadastro incompleto por chamada direta.
A verificação deve cobrir o instante anterior e posterior ao vencimento de cinco dias, repetição de tarefas futuras e múltiplos bloqueios simultâneos.
O rollback deve preservar documentos, vínculos e atribuições já gravados; retirar o seletor não pode remover a autorização obrigatória por proprietário.