Soluciones · Clínicas dentales

Lista de servicios con marcaje de cobertura por el seguro obligatorio, editable por recepción — no un PDF con precios enviado por correo electrónico.

Un sitio web de clínica dental se juzga por una sola cosa: si la persona encuentra el servicio que necesita, con el precio y con su unidad — por diente, por maxilar, por sesión — y si sabe si entra o no en el seguro. Todo lo demás es decorado. Construimos la estructura que sostiene eso y el panel desde el que el personal lo cambia por sí mismo.

Discută scenariul tău

Ya construidoLucrarea 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.

Una clínica dental no vende «servicios». Vende una lista muy larga de posiciones tarifarias con unidades que no se parecen a nada de otro sector: por diente, por maxilar, por extracción, por caso tratado, por sesión, por visita, por intervención. La persona que busca en internet no busca la clínica, sino su posición: cuánto cuesta una extracción, se paga por diente o por visita, está cubierta por el seguro. Un sitio web que responde a eso es útil; uno que tiene una página «Precios» con un PDF adjunto no lo es.

La segunda cosa que exige la realidad de una clínica es que la lista pueda cambiarse sin programador. Las tarifas cambian, los médicos cambian, el horario de urgencias se anuncia de otra manera en invierno. Si cada cambio pasa por un desarrollador, la lista se queda vieja y, en unos meses, los pacientes vienen con el precio del año pasado. La estructura que construimos mantiene los datos públicos — servicios y equipo — en archivos estructurados leídos tanto por la interfaz de programación como directamente por la parte visible del sitio, y el personal los edita desde un panel.

La tercera cosa, que nadie pide en el brief y que importa más, es quién puede escribir en esa lista. Al hacerse cargo del proyecto sobre el que escribimos aquí, cualquiera en internet podía enviar una escritura a la interfaz de programación, y la contraseña del panel llegaba al paquete JavaScript servido al navegador — porque su verificación se hacía en el navegador. Trasladamos la verificación al servidor: la contraseña ya no sale del servidor, se devuelve un token firmado válido durante doce horas, con un límite de ocho intentos por quince minutos por dirección IP y comparaciones en tiempo constante; la interfaz escucha solo en la dirección local, así que el servidor web es la única vía pública.

La marca de cobertura mediante el seguro obligatorio merece una frase separada, porque es el campo con el mayor valor para el paciente y el mayor riesgo para la clínica: es una afirmación con consecuencias. Por eso vive como dato editado por la institución, no como texto escrito por nosotros en una página; nosotros construimos el campo, la visualización y la posibilidad de corregirlo en un minuto.

Qué incluye

Qué cambia concretamente en las clínicas dentales

Cada servicio es una posición con su propia unidad, no una fila en una tabla de precios

La estructura de datos de cada servicio tiene categoría, subcategoría, denominación, precio, unidad de medida e indicador de elegibilidad para el seguro obligatorio. Las unidades son las reales del sector: diente, maxilar, extracción, caso tratado, sesión, visita, consulta, anestesia, procedimiento, investigación, intervención, porque un precio sin unidad produce exactamente la conversación que la recepción quiere evitar.

Taxonomía en dos niveles, para que la lista larga siga siendo recorrible

Categoría y subcategoría, no una lista plana. En el trabajo del que escribimos: 7 categorías y 10 subcategorías sobre 89 servicios. El orden de magnitud importa: con menos de cien posiciones, una taxonomía en dos niveles es suficiente; por encima de unos cientos, la estructura ya es otra conversación y lo decimos antes, no después.

La marca de cobertura por seguro, como dato de la institución

El indicador de elegibilidad está en cada servicio, en los datos públicos, y la clínica puede editarlo. En el trabajo citado, 27 de 89 servicios están marcados como elegibles. Nosotros no escribimos qué entra en el seguro ni lo deducimos: es una afirmación de la institución, con consecuencias para el paciente, y debe poder corregirse por ella en cualquier momento.

Pantallas separadas para urgencias, ortodoncia, implantes, pedodoncia

No una sola página de «Servicios». El sitio tiene 22 pantallas, desde servicios y precios hasta urgencias, ortodoncia, implantes, pedodoncia, transparencia y feedback. El motivo es práctico: quien busca «urgencia dental» el domingo por la noche no quiere una página general, y una página de sección tiene algo que decir sobre el horario y sobre lo que se hace en ella.

El personal edita, el desarrollador no está encadenado

Los servicios y el equipo se editan desde un panel, y las escrituras requieren un token válido; las lecturas siguen siendo públicas, para que el sitio funcione sin autenticación. La consecuencia para la clínica: un cambio de tarifa entra el mismo día, no en la siguiente iteración de desarrollo.

La contraseña no sale del servidor, y los intentos están limitados

La autenticación se hace en el servidor y devuelve un token firmado con HMAC-SHA256, válido 12 horas, con un máximo de 8 intentos por 15 minutos por dirección IP y comparaciones en tiempo constante. El secreto de firma se genera por sí solo, en un archivo con permisos restringidos, mantenido fuera del repositorio. Son cifras del código, no principios generales: se pueden leer y cuestionar.

La interfaz de programación no está expuesta directamente en internet

Escucha solo en la dirección local, así que el servidor web de delante es la única vía pública; la lista de dominios permitidos es explícita, y el cuerpo de las solicitudes está limitado a 1 MB. Las escrituras requieren token, las lecturas no. Es una configuración habitual; el problema es que, cuando falta, no se ve desde fuera hasta el día en que alguien la encuentra.

La integración continua rechaza el paquete si encuentra un secreto en él

La verificación que compila y comprueba los tipos hace también algo que pocos proyectos hacen: busca secretos en el paquete construido y falla si encuentra alguno. Está directamente ligada al defecto corregido en la transferencia: una contraseña había llegado al paquete público precisamente porque nada comprobaba eso. Encima de eso, actualizaciones de dependencias con ritmo semanal.

Qué no hace un sitio web de clínica dental

No confirma una cita por sí solo: recoge la solicitud, y la confirmación requiere a una persona o una conexión al sistema de citas de la clínica — trabajo separado, con sus propias condiciones. No publica información clínica escrita por nosotros: el contenido sobre tratamientos es responsabilidad de los especialistas. Y no decide qué entra en el seguro.

Traseul

Cómo pasa una solicitud por el sistema.

Inventariamos el nomenclátor antes del diseño

La primera entrega es la lista de posiciones tarifarias con la unidad de cada una y con el marcaje de cobertura, en la forma en que la lleva la clínica. Si la lista no existe en una forma estructurada —y por lo general existe como archivo de cálculo o como documento— la estructuramos nosotros, y la clínica la confirma. El diseño viene después, porque depende de cuántas posiciones hay.

Construimos la estructura pública y el panel, en la misma etapa

Las pantallas públicas y el panel desde el que se edita no se hacen por separado, porque de otro modo aparecen campos mostrados que no se pueden editar. Entregamos el sitio web con los datos reales cargados, no con contenido de relleno — un sitio de clínica lleno de texto provisional no puede ser evaluado por nadie.

Cerramos las escrituras y verificamos desde fuera

Autenticación en el servidor, token firmado, límite de intentos, la interfaz de programación solo en la dirección local, lista de dominios permitidos, límite en el cuerpo de las solicitudes. Entregamos el resultado de una verificación hecha desde fuera: qué se puede leer sin autenticación y qué no se puede escribir.

Entregamos con formación para quien edita, no solo con contraseñas

Entregamos los accesos, el documento de puesta en funcionamiento y una formación breve para la persona que cambiará las tarifas y el equipo. La entrega no se considera finalizada hasta que alguien de la clínica no haya hecho, solo, una modificación que aparezca en el sitio web.

4 straturi

Los datos

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

Las reglas difieren de una industria a otra. Estas son las que se aplican en las clínicas dentales.

Qué es público y qué no, en un sitio web de clínica: Público: la lista de servicios con unidad y marcaje de cobertura, el equipo, el horario, los contactos de la institución. No público: todo lo que llega de un formulario. La distinción parece obvia hasta que alguien pone en la página de comentarios un mensaje con su nombre y su problema — por eso los formularios y la visualización pública nunca comparten la misma fuente.
La solicitud de cita contiene datos sobre la salud: «Me duele la muela del juicio inferior izquierda» es una información sobre la salud de una persona identificable, de una categoría con un régimen más estricto. Las consecuencias prácticas se establecen en la implementación: quién tiene acceso a los mensajes recibidos, cuánto se conservan, por qué canal llegan y qué nunca se pide en el formulario.
Los precios y el marcaje de cobertura pertenecen a la institución: Los construimos como estructura y como panel; su contenido es de la clínica y se cambia por decisión suya. No publicamos ninguna cifra de tarifa como ejemplo en nuestros materiales, ni siquiera con carácter ilustrativo — una tarifa sacada de contexto se convierte en una afirmación sobre la clínica.
Quién puede escribir en los datos públicos: Solo quien tiene un token válido, obtenido mediante autenticación en el servidor, con límite de intentos. Las lecturas son públicas porque deben serlo. La diferencia entre estas dos frases es exactamente el defecto que corregimos al asumir el proyecto citado.
Qué queda en el historial del repositorio: El historial de un proyecto contiene, casi siempre, datos que nadie puso allí a propósito: un número de teléfono, una dirección de correo electrónico, el nombre del administrador de contenido. Los tratamos como tal: no se incluyen en materiales públicos y se eliminan del contenido a petición del cliente.

Un caso

Una contraseña de administrador que llegaba en el paquete servido al navegador

La situación

Al asumir un sitio de centro odontológico, el panel de administración tenía dos problemas que solo se veían desde dentro. Primero: la contraseña se comparaba en el navegador, así que llegaba en el paquete JavaScript público. Segundo: las solicitudes de escritura hacia la interfaz de programación podían hacerlas cualquiera desde internet, y el puerto estaba expuesto directamente.

Qué construimos

Movimos la verificación al servidor: la autenticación devuelve un token firmado con HMAC-SHA256, válido durante 12 horas, con un límite de 8 intentos cada 15 minutos por dirección IP y comparaciones en tiempo constante; el secreto de firma se genera solo, con permisos restringidos, fuera del repositorio. La interfaz de programación quedó escuchando solo en la dirección local, con el servidor web delante, lista de dominios permitidos y cuerpo de solicitud limitado a 1 MB. Las escrituras en servicios y en el equipo requieren token; las lecturas siguieron siendo públicas. Encima de todo, integración continua que compila, verifica los tipos y rechaza el paquete si encuentra un secreto en él.

Qué salió

Los datos públicos de la clínica se pueden verificar desde fuera hoy también: 89 servicios, cada uno con categoría, subcategoría, precio, unidad e indicador de cobertura por seguro, de los cuales 27 están marcados como elegibles. Lo que cambió es quién puede escribir en ellos.

Qué no dice el caso

No nosotros construimos la primera versión del sitio. Del historial del repositorio, una parte de los commits son de desarrolladores externos. La contribución que podemos mostrar con diff es la asunción: seguridad, integración continua, tipos, dependencias.

Preguntas

Qué pregunta alguien de clínicas odontológicas

¿Podemos cambiar nosotros mismos los precios, sin llamarlos?

Sí — eso es la mitad del trabajo. Los servicios y el equipo se editan desde un panel; las escrituras requieren autenticación, las lecturas siguen siendo públicas. Nuestra recomendación: en la entrega, la persona que se va a ocupar hace el cambio delante de nosotros, para saber que funciona desde su mano, no desde la nuestra.

¿Cómo mostramos qué entra en el seguro obligatorio?

Como un indicador en cada servicio, en los mismos datos que editáis. En el trabajo que citamos, 27 de 89 servicios están marcados como elegibles. Nosotros construimos el campo y la visualización; qué es elegible exactamente es la afirmación de la institución, porque tiene consecuencias para el paciente y para la clínica.

¿Por qué importa la unidad de medida en un precio?

Porque en odontología el precio no es por visita. Es por diente, por maxilar, por extracción, por caso tratado, por sesión. Un precio mostrado sin unidad produce exactamente la conversación que recepción tiene diez veces al día y, peor aún, la sensación del paciente de que le dijeron otra cosa por teléfono.

¿El sitio puede hacer programaciones?

Puede recopilar la solicitud. La confirmación de una hora requiere o bien una persona que mire la agenda, o bien una conexión al sistema de programaciones de la clínica — es un trabajo separado, con verificación de compatibilidad antes. No llamamos “programación online” a un formulario que envía un correo electrónico.

¿Quién escribe los textos sobre tratamientos?

Los especialistas de la clínica. Nosotros no escribimos información clínica ni la «optimizamos» para la búsqueda, porque eso significaría formular afirmaciones médicas en nombre de una institución médica. Estructuramos, planteamos las preguntas a las que el texto debe responder y lo publicamos después de que se confirma.

Ya tengo un sitio hecho por otra persona. ¿Pueden hacerse cargo?

Sí, y el trabajo sobre el que escribimos aquí es exactamente eso. Lo primero que hacemos en una toma de control: vemos qué se puede escribir desde fuera, dónde están las contraseñas y qué llega en el paquete que se sirve al navegador. En el caso citado, la contraseña de administrador llegaba en el paquete público, y las escrituras las podía hacer cualquiera. Trasladamos la verificación al servidor y cerramos las escrituras.

¿Qué tan rápido se ve un cambio de tarifa?

En cuanto se guarda, porque los datos públicos se leen de la misma fuente que editas. Lo que no prometemos es la velocidad con la que se actualizan los resultados de los motores de búsqueda — eso no depende de nosotros y no podemos garantizarlo.

¿Qué pasa con los datos del formulario de contacto?

Se establece en la implementación: a dónde llegan, quién los ve, cuánto tiempo se conservan y qué no se pide nunca en el formulario. En una clínica, el mensaje suele contener una descripción de un problema de salud, así que no es «un lead», es una categoría de datos con régimen estricto — y su tratamiento se escribe en la política publicada de la clínica.

¿El sitio dirá que fue hecho por ustedes?

Solo si quieres. Algunos de nuestros trabajos llevan atribución en el pie de página, otros no — depende del cliente. Lo mencionamos porque es una pregunta que hacen las clínicas y porque, cuando el sitio no lleva ninguna atribución, nosotros tampoco nos presentamos como autores sin su acuerdo.

Serviciul, în detaliu Toate scenariile

¿Qué te gustaría que funcionara mejor?

Cuéntanos tu proceso. Juntos decidimos qué merece la pena construir, qué podemos conectar y cómo verificamos el resultado.

Vamos a hablar