Saltar para o conteúdo
megapromotingVamos falar

Soluções · Clínicas dentárias

Lista de serviços com marcação de cobertura pelo seguro obrigatório, editável pela receção — não um PDF com preços enviado por e-mail.

Um site de clínica dentária é avaliado por uma única coisa: se a pessoa encontra o serviço de que precisa, com o preço e a sua unidade — por dente, por maxilar, por sessão — e se sabe se entra ou não no seguro. O resto é decoração. Construímos a estrutura que sustenta isso e o painel a partir do qual o pessoal o altera por si próprio.

Já construídoLucrarea se poate verifica din exterior chiar acum: datele publice ale unui centru stomatologic raional pe care îl administrăm sunt servite ca fișier structurat — 89 de servicii, fiecare cu categorie, subcategorie, denumire, preț, unitate de măsură și un indicator de eligibilitate pentru asigurarea obligatorie, dintre care 27 marcate ca eligibile; 7 categorii și 10 subcategorii, verificate de noi pe 06.09.2026. A doua parte a dovezii e securizarea, cu diff în istoric: la preluare, parola de administrator era comparată în browser și ajungea în pachetul JavaScript public, iar scrierile pe interfața de programare se puteau face de oricine de pe internet. Precizarea corectă, ca să nu ne atribuim mai mult decât e al nostru: prima variantă a site-ului nu e a noastră. Contribuția care se poate arăta cu diff e preluarea, securizarea, tipurile, integrarea continuă și igiena dependințelor.

Uma clínica dentária não vende «serviços». Vende uma lista muito longa de posições tarifárias com unidades que não se parecem com nada de outro domínio: por dente, por maxilar, por extração, por caso tratado, por sessão, por visita, por intervenção. A pessoa que procura na internet não procura a clínica, mas a sua posição: quanto custa uma extração, paga-se por dente ou por visita, é coberta pelo seguro. Um site que responde a isso é útil; um que tem uma página «Preços» com um PDF anexado não é.

A segunda coisa que a realidade de uma clínica exige é que a lista seja alterável sem programador. As tarifas mudam, os médicos mudam, o horário de urgências anuncia-se de outra forma no inverno. Se cada alteração passa por um desenvolvedor, a lista fica antiga e, em poucos meses, os pacientes vêm com o preço do ano passado. A estrutura que construímos mantém os dados públicos — serviços e equipa — em ficheiros estruturados lidos tanto pela interface de programação como diretamente pela parte visível do site, e o pessoal edita-os a partir de um painel.

A terceira coisa, que ninguém pede no brief e que é a mais importante, é quem pode escrever nessa lista. Na tomada de controlo do projeto sobre o qual escrevemos aqui, qualquer pessoa da internet podia enviar uma escrita para a interface de programação, e a palavra-passe do painel acabava no pacote JavaScript servido ao browser — porque a verificação era feita no browser. Movemos a verificação para o servidor: a palavra-passe já não sai do servidor, regressa um token assinado válido por doze horas, com limite de oito tentativas por quinze minutos por endereço IP e comparações em tempo constante; a interface só escuta no endereço local, portanto o servidor web é a única via pública.

A marcação da cobertura por seguro obrigatório merece uma frase separada, porque é o campo com o maior valor para o paciente e o maior risco para a clínica: é uma afirmação com consequências. Por isso, ela existe como dado editado pela instituição, não como texto escrito por nós numa página; nós construímos o campo, a exibição e a possibilidade de o corrigir num minuto.

Qué incluye

O que muda concretamente nas clínicas dentárias

Cada serviço é uma posição com a sua unidade, não uma linha numa tabela de preços

A estrutura de dados de cada serviço tem categoria, subcategoria, designação, preço, unidade de medida e indicador de elegibilidade para o seguro obrigatório. As unidades são as reais do domínio — dente, maxilar, extração, caso tratado, sessão, visita, consulta, anestesia, procedimento, exame, intervenção — porque um preço sem unidade produz exatamente a conversa que a receção quer evitar.

A taxonomia em dois níveis, para que a lista longa permaneça percorrível

Categoria e subcategoria, não uma lista plana. No trabalho sobre o qual escrevemos: 7 categorias e 10 subcategorias em mais de 89 serviços. A ordem de grandeza conta — com menos de uma centena de posições, uma taxonomia em dois níveis é suficiente; acima de algumas centenas, a estrutura torna-se outra conversa e nós dizemo-lo antes, não depois.

A marcação da cobertura por seguro, como dado da instituição

O indicador de elegibilidade está em cada serviço, nos dados públicos, e pode ser editado pela clínica. No trabalho citado, 27 de 89 serviços estão marcados como elegíveis. Não somos nós que escrevemos o que entra no seguro e não o deduzimos: é uma afirmação da instituição, com consequências para o paciente, e deve poder ser corrigida por ela em qualquer momento.

Ecrãs separados para urgências, ortodontia, implantes, pedodontia

Não uma única página “Serviços”. O site tem 22 ecrãs, desde serviços e preços até urgências, ortodontia, implantes, pedodontia, transparência e feedback. A razão é prática: quem procura “urgência dentária” ao domingo à noite não quer uma página geral, e uma página de secção tem o que dizer sobre o horário e sobre o que se faz nela.

A equipa edita, o desenvolvedor não fica na cadeia

Os serviços e a equipa são editados a partir de um painel, e as escritas exigem um token válido; as leituras permanecem públicas, para que o site funcione sem autenticação. Consequência para a clínica: uma alteração de tarifa entra no mesmo dia, não na iteração seguinte de desenvolvimento.

A palavra-passe não sai do servidor, e as tentativas são limitadas

A autenticação é feita no servidor e devolve um token assinado com HMAC-SHA256, válido por 12 horas, com no máximo 8 tentativas por 15 minutos por endereço IP e comparações em tempo constante. O segredo de assinatura é gerado automaticamente, num ficheiro com permissões restritas, mantido fora do repositório. São números do código, não princípios gerais — podem ser lidos e contestados.

A interface de programação não é exposta diretamente na internet

Escuta apenas no endereço local, portanto o servidor web da frente é a única via pública; a lista de domínios permitidos é explícita, e o corpo dos pedidos é limitado a 1 MB. As escritas exigem token, as leituras não. É uma configuração comum — o problema é que, quando falta, não se vê do exterior até ao dia em que alguém a encontra.

A integração contínua rejeita o pacote se encontrar um segredo nele

A verificação que compila e verifica os tipos faz também uma coisa que poucos projetos fazem: procura segredos no pacote construído e falha se encontrar. Está diretamente ligada ao defeito corrigido na importação — uma palavra-passe tinha chegado ao pacote público precisamente porque nada verificava isso. Além disso, atualizações de dependências com ritmo semanal.

O que um site de clínica dentária não faz

Não confirma por si só uma marcação: recolhe o pedido, e a confirmação exige ou uma pessoa, ou uma ligação ao sistema de marcações da clínica — trabalho separado, com as suas próprias condições. Não publica informação clínica escrita por nós: o conteúdo sobre tratamentos é da responsabilidade dos especialistas. E não decide o que entra no seguro.

Traseul

Como um pedido passa pelo sistema.

01

Inventariamos o catálogo antes do design

A primeira entrega é a lista de itens tarifários com a unidade de cada um e com a marcação de cobertura, na forma em que a clínica a mantém. Se a lista não existir numa forma estruturada — e normalmente existe como ficheiro de cálculo ou como documento — nós estruturamo-la, e a clínica confirma-a. O design vem depois, porque depende de quantos itens existem.

02

Construímos a estrutura pública e o painel, na mesma fase

Os ecrãs públicos e o painel a partir do qual se edita não são feitos separadamente, porque de outro modo aparecem campos exibidos que não podem ser editados. Entregamos o site com os dados reais carregados, não com conteúdo de preenchimento — um site de clínica cheio de texto provisório não pode ser avaliado por ninguém.

03

Fechamos as escritas e verificamos externamente

Autenticação no servidor, token assinado, limite de tentativas, interface de marcação apenas no endereço local, lista de domínios permitidos, limite no corpo dos pedidos. Entregamos o resultado de uma verificação feita de fora: o que pode ser lido sem autenticação e o que não pode ser escrito.

04

Entregamos com formação para quem edita, não só com palavras-passe

Entregamos os acessos, o documento de colocação em funcionamento e uma formação breve para a pessoa que vai alterar os preços e a equipa. A entrega não é considerada concluída até alguém da clínica ter feito, sozinho, uma alteração que apareça no site.

1Server web în față2pachet static construit3interfață de programare doar pe adresa locală4fișiere structurate cu serviciile și echipaCitirile trec public; scrierile cer un jeton semnat, valabil 12 ore.
4 straturi

Os dados

Qué tocamos, dónde están y cuánto se quedan

As regras diferem de indústria para indústria. Estas são as que se aplicam às clínicas dentárias.

O que é público e o que não é, num site de clínica
Público: a lista de serviços com unidade e marcação de cobertura, a equipa, o horário, os contactos da instituição. Não público: tudo o que chega de um formulário. A distinção parece evidente até alguém colocar na página de feedback uma mensagem com o nome e o problema — por isso os formulários e a exibição pública nunca partilham a mesma fonte.
O pedido de marcação contém dados sobre saúde
«Estou com dor no dente do siso inferior esquerdo» é uma informação sobre a saúde de uma pessoa identificável, de uma categoria com regime mais estrito. As consequências práticas são definidas na implementação: quem tem acesso às mensagens recebidas, quanto tempo são guardadas, por que canal chegam e o que nunca se pede no formulário.
Os preços e a marcação de cobertura pertencem à instituição
Nós construímo-los como estrutura e como painel; o conteúdo é da clínica e muda por decisão dela. Não publicamos nenhum valor de tarifa como exemplo nos nossos materiais, nem com fim ilustrativo — uma tarifa retirada do contexto torna-se uma afirmação sobre a clínica.
Quem pode escrever nos dados públicos
Só quem tem um jeton válido, obtido através de autenticação no servidor, com limite de tentativas. As leituras são públicas porque têm de ser. A diferença entre estas duas frases é exatamente o defeito que corrigimos ao assumir o projeto citado.
O que fica no histórico do repositório
Um histórico de projeto contém, quase sempre, dados que ninguém colocou ali de propósito: um número de telefone, um endereço de e-mail, o nome do administrador de conteúdo. Tratamo-los como tal — não são incluídos em materiais públicos e são removidos do conteúdo a pedido do cliente.

Un caso

Uma palavra-passe de administrador que acabava no pacote servido ao browser

A situação

Ao assumir um site de um centro odontológico, o painel de administração tinha dois problemas que só se viam de dentro. Primeiro: a palavra-passe era comparada no browser, por isso acabava no pacote JavaScript público. Segundo: os pedidos de escrita para a interface de programação podiam ser feitos por qualquer pessoa na internet, e a porta estava exposta diretamente.

Qué construimos

Passámos a verificação para o servidor: a autenticação devolve um jeton assinado com HMAC-SHA256, válido por 12 horas, com limite de 8 tentativas por 15 minutos por endereço IP e comparações em tempo constante; o segredo de assinatura é gerado automaticamente, com direitos restritos, fora do repositório. A interface de programação ficou a escutar apenas no endereço local, com o servidor web à frente, lista de domínios permitidos e corpo do pedido limitado a 1 MB. As escritas para serviços e equipa exigem jeton; as leituras mantiveram-se públicas. Por cima de tudo, integração contínua que compila, verifica os tipos e recusa o pacote se encontrar um segredo nele.

Qué salió

Os dados públicos da clínica podem ser verificados do exterior ainda hoje: 89 serviços, cada um com categoria, subcategoria, preço, unidade e indicador de cobertura por seguro, dos quais 27 marcados como elegíveis. O que mudou foi quem pode escrever neles.

Qué no dice el caso

Não fomos nós que construímos a primeira versão do site. Pelo histórico do repositório, parte dos commits é de desenvolvedores externos. A contribuição que podemos mostrar com diff é a assunção: segurança, integração contínua, tipos, dependências.

Perguntas

O que pergunta alguém de clínicas odontológicas

Podemos alterar os preços sozinhos, sem vos telefonar?

Sim — essa é metade do trabalho. Os serviços e a equipa são editados a partir de um painel; as escritas exigem autenticação, as leituras continuam públicas. A nossa recomendação: na entrega, a pessoa que se vai ocupar faz a alteração à nossa frente, para sabermos que funciona da parte dela, e não da nossa.

Como mostramos o que entra no seguro obrigatório?

Como indicador em cada serviço, nos mesmos dados que vocês editam. No trabalho que citamos, 27 de 89 serviços estão marcados como elegíveis. Nós construímos o campo e a apresentação; o que é elegível é a afirmação da instituição, porque tem consequências para o paciente e para a clínica.

Porque é que a unidade de medida importa num preço?

Porque em odontologia o preço não é por visita. É por dente, por maxilar, por extração, por caso tratado, por sessão. Um preço apresentado sem unidade produz exatamente a conversa que a receção tem dez vezes por dia e, pior, a sensação do paciente de que lhe foi dito outra coisa ao telefone.

O site pode fazer marcações?

Pode recolher o pedido. A confirmação de uma hora exige ou uma pessoa a consultar a agenda, ou uma ligação ao sistema de marcações da clínica — é um trabalho separado, com verificação de compatibilidade antes. Não chamamos «marcação online» a um formulário que envia um e-mail.

Quem escreve os textos sobre tratamentos?

Os especialistas da clínica. Nós não escrevemos informação clínica nem a «optimizamos» para pesquisa, porque isso significaria formular afirmações médicas em nome de uma instituição médica. Estruturamos, colocamos as perguntas às quais o texto tem de responder e publicamo-lo depois de confirmado.

Já tenho um site feito por outra pessoa. Vocês podem assumi-lo?

Sim, e o trabalho de que falamos aqui é exatamente isso. O que fazemos primeiro numa assunção: vemos o que pode ser escrito de fora, onde estão as palavras-passe e o que entra no pacote servido ao browser. No caso citado, a palavra-passe de administrador entrava no pacote público, e as escritas podiam ser feitas por qualquer pessoa. Mudámos a verificação para o servidor e fechámos as escritas.

Com que rapidez se vê uma alteração de tarifa?

Assim que é guardada, porque os dados públicos são lidos da mesma fonte que você edita. O que não prometemos é a rapidez com que os resultados nos motores de pesquisa são atualizados — isso não depende de nós e não o podemos garantir.

O que acontece com os dados do formulário de contacto?

É definido na implementação: para onde vão, quem os vê, durante quanto tempo são guardados e o que nunca é pedido no formulário. Numa clínica, a mensagem contém muitas vezes uma descrição de um problema de saúde, por isso não é «um lead», é uma categoria de dados com regime estrito — e o seu tratamento é escrito na política publicada da clínica.

O site vai dizer que foi feito por vocês?

Só se quiserem. Alguns dos nossos trabalhos têm atribuição no rodapé, outros não — depende do cliente. Mencionamos isto porque é uma pergunta que as clínicas fazem e porque, quando o site não tem qualquer atribuição, também nós não nos apresentamos como autores sem o consentimento deles.

O que gostaria que funcionasse melhor?

Conte-nos o seu processo. Em conjunto decidimos o que vale a pena construir, o que podemos ligar e como verificamos o resultado.

Vamos falar