scoreodonto.com/doc/ANALISE-AREA-RECEPCAO-TC.md

Análise — Área da Recepção / Coordenação de Tratamentos (Treatment Coordinator)

Gatilho (23/jun/2026): recep.consulttclinic@gmail.com lançou uma prótese mas não tinha a aba para acompanhá-la. Análise do gap + recomendação fundamentada em modelos validados de software odontológico. Conecta com FASE2-PROTETICO-AREA.md (o outro lado do fluxo).

---

1. Diagnóstico (DEV scoreodonto_dev)

Entidade	Achado
Dono	consulttclinic@gmail.com → Rui Cesar, donoclinica
Funcionária	recep.consulttclinic@gmail.com (u_1780962424310_cqsxn), role funcionario, vínculo na CONSULTT CLINIC LTDA (c_1780871001549_koqa3o)
Cargo	função "Recepcionista" (fnc_1780962382528_m28go)
Permissões (antes)	["agenda","ortodontia","contratos","tratamentos","pacientes","lancar-gto"]
Prótese lançada	OS pos_1782228267898_zgfzn — Prótese Total, paciente ABIGAIR, R$600, protético "Zeca Andrade Fake", status solicitado, via GTO (gto_item_id=QOJWR6D)

Gap exato: o cargo tinha lancar-gto (lançar) mas não proteses (acompanhar). O RBAC da Sidebar.tsx é literal (return wsPerms.includes(item.id)), então a OS criada por ela ficava invisível para ela própria. A Fase 1 (GTO→OS) funcionou; o problema era de configuração de cargo, não de arquitetura.

---

2. Modelos validados (referência externa)

• Papel = "Treatment Coordinator" + Front Desk. É a ponte entre paciente e equipe clínica: sequencia planos multi-etapa, conduz o aceite do caso (case acceptance), arranjo financeiro e follow-up até a conclusão — exatamente "gerir tratamentos" de ponta a ponta.
• RBAC por papel é o padrão. Permissões mapeadas a papéis, não a indivíduos; o front desk recebe agenda/cadastro/cobrança, tipicamente sem notas clínicas. O ScoreOdonto já faz isso via funcoes.permissoes[].
• Prótese = "Lab Case", acompanhada pelo front desk. No Dentrix Lab Case Manager: clínico cria a prescrição → status Sent → o front desk muda para Received quando volta do lab → Finished ao assentar. Ou seja: acompanhar a OS de prótese é, por modelo consagrado, atribuição da recepção — o acesso que faltava.

Fontes:

• The Role of a Treatment Coordinator — https://www.dentalmanagers.com/blog/role-of-treatment-coordinator-in-dental-practice/
• What Does a Treatment Plan Coordinator Do? — https://www.teero.com/blog/treatment-plan-coordinator
• Dental Software User Permissions (Curve) — https://www.curvedental.com/blog/dental-software-user-permissions
• RBAC in Healthcare — https://www.accountablehq.com/post/role-based-access-control-rbac-in-healthcare-benefits-examples-and-best-practices
• Manage Your Lab Cases in Dentrix — https://magazine.dentrix.com/manage-your-lab-cases-in-dentrix/
• Open Dental — Lab Cases — https://www.opendental.com/manual/labcasemanage.html

---

3. Ação aplicada — Nível 1 (configuração, sem código)

✅ Aplicado no DEV em 23/jun/2026. Função "Recepcionista" da CONSULTT CLINIC LTDA atualizada:

UPDATE funcoes
   SET permissoes = '["agenda","pacientes","tratamentos","ortodontia","proteses","lancar-gto","orcamentos","contratos"]'
 WHERE id = 'fnc_1780962382528_m28go';   -- UPDATE 1

Acréscimos: proteses (acompanhar a OS que ela lança) e orcamentos (case acceptance — coração do papel TC). Efeito imediato: a OS pos_1782228267898_zgfzn passa a aparecer para ela.

Escopo: alteração só no DEV. Não há mudança de código nem migração — é dado de configuração. Para refletir em outras clínicas, ajustar o cargo equivalente de cada uma (ou rever o template de cargos padrão, se existir).

---

3b. Causa raiz (investigação 23/jun) — proteses não é concedível pela UI

A correção de dado acima trata o sintoma. A causa raiz é um bug de configuração de RBAC:

• Cargos não têm seed no backend (signup não cria funções). São criados manualmente pelo dono em Gestão de Equipe (POST → INSERT INTO funcoes, server.js:806), partindo de 4 templates do frontend (GestaoEquipeView.tsx:96).
• Nenhum template inclui proteses: RECEPÇÃO (dashboard,agenda,pacientes,leads,orcamentos), AUXILIAR (...,ortodontia,tratamentos), FINANCEIRO (...,financeiro,relatorios,lancar-gto), GERENTE ([...TODAS_PAGINAS]).
• Raiz: proteses não está em PAGINAS_RBAC (GestaoEquipeView.tsx:57), a lista mestre de páginas atribuíveis. Como TODAS_PAGINAS = PAGINAS_RBAC.flatMap(...), nem o GERENTE / "MARCAR TODAS" concede prótese. ⇒ É impossível um dono dar proteses a um funcionário pela interface — só via UPDATE direto no banco (o que foi feito na §3).
• Também ausentes da lista atribuível, embora em uso: contratos (a função tinha — legado), comissoes, glosas.

Resposta à pergunta "o cargo Recepcionista padrão nasce sem proteses?": Sim — e mais, nenhum cargo consegue tê-la pela UI hoje.

Fix de raiz (código) — ✅ aplicado e validado no DEV (23/jun)

Em frontend/views/GestaoEquipeView.tsx:

• PAGINAS_RBAC, grupo ATENDIMENTO: + { key: 'proteses', label: 'PRÓTESES' } e { key: 'contratos', label: 'CONTRATOS' } → agora concedíveis pela UI (e entram em TODAS_PAGINAS/GERENTE/"MARCAR TODAS").
• Templates: RECEPÇÃO ganhou contratos, lancar-gto, proteses; AUXILIAR ganhou proteses (alinhado ao papel TC).

Validação: vite build transformou 2382 módulos OK; container DEV rebuildado e no ar; o bundle servido pelo nginx DEV (index-*.js, alvo de dev.scoreodonto.com) contém key:"proteses",label:"PRÓTESES" e a string proteses nos 3 pontos editados. Cargos padrão passam a nascer coerentes — sem UPDATE manual por clínica.

⚠️ Pendente de commit + deploy à produção (a mudança está só no DEV). Os fixes de dado (§3, função da CONSULTT CLINIC) continuam sendo só-DEV e não se propagam por este fix de código.

4. Recomendação — Nível 2 (estrutural, "Fase 3")

Em vez de abas soltas (tratamentos, proteses, ortodontia), um hub de Coordenação de Tratamentos por paciente: pipeline único com o status de cada frente (clínico / prótese-lab / orto), espelhando o "lab case visível para toda a equipe" do Dentrix. View nova que agrega o que já existe (tratamentos + protese_os + ortodontia por paciente) — sem dado novo.

5. Conexão com a Fase 2

Dois lados do mesmo fluxo, unidos pela mesma protese_os:

• Fase 2 → casa do protético (quem produz; avança status na Bancada).
• Esta análise → recepção/TC (quem encomenda e acompanha; lê o status no hub). O status que o lab avança é o mesmo que a recepção lê — o "Lab Case Manager" repartido entre os papéis.

---

6. Salas: acesso do funcionário corrigido + bloqueio de manutenção (23/jun)

Gatilho: a mesma recepcionista aparecia com MINHAS SALAS e ALUGAR SALAS (gestão de locação, de titular) e deveria ter apenas a agenda da sala e o bloqueio para manutenção.

6a. Bug — vazamento dos menus de locação ✅ corrigido (Sidebar.tsx)

MINHAS SALAS (locador) e ALUGAR SALAS (locatário) eram empurrados a "todos menos superadmin" (Sidebar.tsx:42), vazando para funcionário e paciente — papéis que não são titulares de sala. Passaram a exibir apenas a PAPEIS_LOCACAO (donosala/donoclinica/donoconsultorio/admin/dentista/biomedico/protetico). O backend já era seguro por ownership; era vazamento só de UI.

6b. Feature — acesso operacional + manutenção ✅ implementada e validada no DEV

Não existia caminho para "funcionário vê só a agenda" nem "bloqueio para manutenção" — foram criados (modelos de mercado: Dentrix/Open Dental Lab... não; aqui é gestão de espaço — o padrão é front desk opera a agenda da sala sem tocar no financeiro do locador).

• Acesso operacional (server.js listarWorkspaces): sala cuja clinica_id é uma clínica onde o usuário tem vínculo (e ele não é o dono) entra como workspace tipo='sala' com papel_sala='operador'. O SalaHomeView detecta o modo operador e esconde recebíveis, relatório e baixa — mostra só a agenda + botão de bloqueio.
• Bloqueio de manutenção (POST /api/salas/:id/manutencao): reserva tipo='manutencao' (coluna nova, default 'locacao'), valor=0, nasce 'confirmada' (sem aprovação) e não gera recebível. Acesso: dono ou membro com vínculo na clínica da sala. Reaproveita o anti-conflito de horário (409) e o cancelamento por solicitante/unidade. A agenda renderiza o bloqueio em cinza (legenda "Manutenção").

Validação ponta a ponta (DEV, JWT real da recepcionista, sala de teste vinculada à clínica):

Caso	Resultado
Sala da clínica vira workspace operador dela	✅ query retorna a sala
POST bloqueio	✅ status:confirmada, tipo:manutencao
GET agenda mostra bloqueio + motivo	✅ valor:0, motivo:"Conserto do equipo"
Conflito de horário	✅ HTTP 409
Não gera financeiro	✅ 0 lançamentos

Commits: fix(salas) (menu) + feat(salas) (operador + manutenção). Backend e frontend no ar no DEV; dados de teste limpos.

⚠️ Pendente de push + deploy (produção segue em v1.0.19).