De uma operação clínica fragmentada a uma única plataforma de gestão.

O Centro Dentário Colombo opera duas clínicas: uma no Centro Comercial Colombo com cinco gabinetes e médicos rotativos, outra na Buraca com um gabinete e um único médico. A operação corria num software de gestão legado (Dentoral) que a equipa queria substituir por completo.

Comecei por construir o website institucional da clínica. Quando a direção viu o que era possível, o pedido cresceu: um sistema que cobrisse pacientes, agenda, registo clínico, cobranças, faturação, comissões de médicos, stock e portal do paciente — com dados clínicos globais e operação segregada por clínica.

A informação vivia em vários sítios: agenda num sistema, comissões em folhas de cálculo, stock de cabeça, confirmações de consulta por telefone. Erros de dupla marcação e de cobrança eram frequentes e difíceis de reconstruir depois.

Os médicos precisavam de ver a sua agenda e produção no telemóvel — no carro, entre clínicas — e os pacientes precisavam de confirmar presença e aceder a documentos sem ligar para a receção.

Depois de uma apresentação aos sócios, recebi 37 requisitos de melhoria (E1–E19, P1–P16, X1–X2). Tinham de ser faseados sem parar a operação.

Único developer e responsável pelo produto: levantamento de requisitos com os sócios, modelação do domínio, arquitetura, implementação, migração de dados do sistema legado, documentação e apresentações de aprovação.

• Dados legados: 749 atos e 22 categorias importados de um sistema que continuava a ser usado durante a migração.
• Exatidão financeira: comissões de médicos e faturação certificada — um cêntimo errado é um problema contabilístico.
• Marcações concorrentes em cinco gabinetes com médicos rotativos.
• Três perfis de utilizador com permissões distintas e dados clínicos sob RGPD.
• Utilizadores reais em produção: a operação não podia parar entre fases.

Uma aplicação Next.js com três áreas — administração/receção, médico e portal do paciente — sobre uma única base de dados MongoDB com mais de 25 modelos. Tudo o que é operacional (agenda, cobrança, faturação, recalls, stock) é segregado por clínica; pacientes e fichas clínicas são globais.

Os 37 requisitos foram organizados num plano de sete fases. A primeira foi o motor financeiro: desconto e custo direto por linha de tratamento, cadeia de resolução de comissões (override do médico → base do médico → taxa do ato → 40% por defeito), cancelamento e estorno. As restantes cobriram agenda, painel do médico, portal do paciente, RX, stock e dashboards. 34 dos 37 pedidos foram entregues; os três restantes dependem de terceiros (leitura do Cartão de Cidadão, PEM/SPMS) ou ficaram para depois da aprovação.

• Agenda multi-clínica com grelha de 15 minutos, horários por clínica e por profissional, correção de DST e prevenção atómica de dupla marcação por transação MongoDB.
• Circuito de três emails por marcação (criação, lembrete por cron, confirmação pública) com página de confirmação sem login.
• Fluxo de consulta orientado por máquina de estados: pending → confirmed → checked-in → in-progress → completed.
• Odontograma SVG de 32 dentes com cinco faces, versionado e imutável; planos de tratamento com execução faseada; notas clínicas append-only.
• Catálogo de 749 atos em 22 categorias importado do sistema legado por script idempotente com dry-run.
• Fila de cobrança por clínica com checkout ao balcão, guarda anti-dupla-cobrança e documentos preparados para emissão certificada via Moloni.
• Módulo de RX com pedido, máquina de estados, assinatura digital do consentimento e captura de imagem via Cloudinary (assets privados, URLs assinados).
• Stock por localização: entradas centrais, requisições para gabinetes, contagens quinzenais, ledger imutável de movimentos, transferências entre clínicas como par atómico.
• Recalls gerados automaticamente na conclusão de atos, com um único ciclo aberto por paciente e tipo de ato.
• Dashboards de administração (KPIs, ocupação, "Requer atenção") e de médico (produção própria, comissões, consultas por fechar).
• Portal do paciente: marcações, confirmação de presença, ficheiro .ics, documentos, dados pessoais, consentimentos RGPD.
• RBAC estrito: só administradores veem produção e comissões dos médicos; receção com âmbito por clínica; médicos só veem os seus dados. Trilho de auditoria em todas as escritas.
• Branding dinâmico (modelo Organization: nome, logo, cor, dados legais, remetente) para o sistema poder ser instalado noutra clínica sem tocar no código.

Next.js 16 App Router com Server Actions como camada principal (uma por domínio: agenda, cobrança, faturação, recalls, stock, configurações). Rotas de API apenas para autenticação, cron de lembretes e integrações.

MongoDB Atlas com Mongoose; transações para invariantes (dupla marcação, dupla cobrança, saldo de stock). Constantes de domínio partilhadas em src/lib/domain.ts sem dependências, para que componentes de cliente nunca arrastem código de servidor.

NextAuth v5 (JWT) com RBAC; Zod para validação e máquinas de transição por domínio; Resend para email (região UE); Cloudinary para imagens privadas; Vercel.

34 dos 37 requisitos do cliente implementados em oito entregas faseadas, com relatório de desenvolvimento e apresentação de aprovação aos sócios.

Sistema pronto para operar as duas clínicas e preparado, com branding dinâmico e isolamento por base de dados, para ser instalado noutras clínicas dentárias.

O que este projeto demonstra: capacidade de levar um produto do levantamento de requisitos com o cliente até um sistema em produção, com decisões de arquitetura pensadas para dados financeiros e clínicos.

Numa segunda iteração começaria pelo modelo de permissões e pelo trilho de auditoria antes do motor financeiro: foram os pontos que mais forçaram refactoring quando chegaram os requisitos dos sócios.

A decisão de uma base de dados por clínica foi certa para vender a segunda instalação depressa, mas a partir de várias clínicas pagantes um organizationId por coleção passa a compensar — o código já está preparado para essa migração.

Next.js 16 · TypeScript · MongoDB Atlas · Mongoose · NextAuth v5 · Zod · Resend · Cloudinary · Tailwind CSS v4 · Vercel