VPS 4 Builder
159 lines
9.3 KiB
Markdown
159 lines
9.3 KiB
Markdown
# 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:
|
|
|
|
```sql
|
|
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).
|