¿Cómo sería una funcionalidad de presupuesto basada en tratamientos apuntados en un odontograma?
En un software odontológico, una función de presupuesto suele ser la consecuencia natural del odontograma. El odontograma registra el estado clínico; el presupuesto traduce ese diagnóstico en un plan económico.
Una arquitectura típica sería:
El odontograma contiene los dientes, caras dentarias y tratamientos indicados.
Cada tratamiento indicado referencia un tipo de prestación (obturación, endodoncia, extracción, corona, etc.).
Al generar un presupuesto, el sistema recorre esos tratamientos y busca el precio vigente de cada prestación.
Se genera un documento de presupuesto independiente del odontograma.
Por ejemplo:
Odontograma
├── Tratamiento: Obturación simple (pieza 16)
├── Tratamiento: Endodoncia (pieza 26)
└── Tratamiento: Corona de porcelana (pieza 11)
↓
Presupuesto
Obturación simple .......... $45.000
Endodoncia ................. $95.000
Corona porcelana .......... $280.000
Total ..................... $420.000
¿Por qué no calcularlo directamente desde el odontograma?
Porque los precios cambian.
Si mañana la corona pasa de $280.000 a $320.000, un presupuesto emitido hace dos meses debe seguir mostrando $280.000.
Por eso normalmente existen dos entidades:
Odontograma → información clínica.
Presupuesto → fotografía comercial en un momento determinado.
Qué tablas tendría
prestaciones
------------
id
codigo
descripcion
precio_actual
...
presupuestos
------------
id
paciente_id
fecha
estado
subtotal
descuento
total
...
presupuesto_items
-----------------
id
presupuesto_id
prestacion_id
pieza
cantidad
precio_unitario
importe
Observá que precio_unitario queda copiado en el presupuesto aunque luego cambie el precio de la prestación.
Flujo de trabajo
El odontólogo marca tratamientos en el odontograma.
Presiona Generar presupuesto.
El sistema propone automáticamente todos los tratamientos pendientes.
El profesional puede quitar algunos, agregar otros o modificar cantidades.
Se guarda el presupuesto.
Más adelante pueden generarse nuevos presupuestos sin modificar el odontograma.
Una mejora interesante
En lugar de guardar en el odontograma un texto como:
{
"tratamiento": "Obturación"
}
conviene guardar el id de la prestación:
{
"prestacionId": 17
}
Así el presupuesto puede obtener automáticamente:
descripción,
precio vigente,
duración estimada,
color para el dibujo,
código interno,
cobertura de obra social, etc.
De esa manera, el odontograma permanece como un documento clínico, mientras que el presupuesto se convierte en una "instantánea" económica generada a partir de él, manteniendo ambos conceptos desacoplados y permitiendo que evolucionen de forma independiente.
Quiero una narración cronológica de cómo va pasando de una instancia a la otra.
Una forma bastante natural de verlo es pensar que cada instancia representa una etapa distinta del trabajo del odontólogo, y que cada una congela cierta información para no depender de cambios posteriores.
1. Odontograma (estado clínico)
El paciente llega al consultorio. El odontólogo examina la boca y registra el estado de cada pieza dental.
Por ejemplo:
Pieza 11: caries.
Pieza 16: restauración en mal estado.
Pieza 26: endodoncia indicada.
En esta etapa no hay decisión terapéutica ni precios. Sólo existe el diagnóstico y el estado de la boca.
Pregunta que responde: ¿Qué tiene el paciente?
2. Treatment Plan (plan de tratamiento)
A partir del diagnóstico, el odontólogo decide qué propone hacer.
Por ejemplo:
Pieza 11 → Restauración con resina.
Pieza 16 → Reemplazar restauración.
Pieza 26 → Endodoncia y luego corona.
Todavía no se habla de dinero. Incluso pueden existir varios planes alternativos.
Por ejemplo:
Plan A: conservar la pieza mediante endodoncia.
Plan B: extraer la pieza e implantar un implante.
Pregunta que responde: ¿Qué tratamiento se propone?
3. Treatment Estimate (presupuesto)
Una vez elegido un plan, el sistema toma cada procedimiento y busca su precio vigente.
El presupuesto queda, por ejemplo:
| Prestación | Precio |
|---|---|
| Restauración | $45.000 |
| Endodoncia | $95.000 |
| Corona | $280.000 |
| Total | $420.000 |
En este momento el presupuesto se congela.
Aunque dentro de un mes la corona aumente a $320.000, este presupuesto seguirá mostrando $280.000.
También puede registrar:
descuentos,
financiación,
obra social,
impuestos,
vigencia del presupuesto.
Pregunta que responde: ¿Cuánto costará?
4. Invoice (factura)
Cuando el paciente acepta el presupuesto y comienzan los tratamientos, llega el momento de facturar.
La factura representa una operación económica real.
Puede ocurrir que:
el presupuesto era por $420.000;
el paciente decidió postergar la corona;
hoy sólo se facturan la restauración y la endodoncia.
La factura queda por $140.000.
Más adelante podrá emitirse otra factura por la corona.
Pregunta que responde: ¿Qué se cobró realmente?
El flujo completo
Paciente llega
│
▼
Odontograma
"¿Qué tiene?"
│
▼
Treatment Plan
"¿Qué proponemos hacer?"
│
▼
Treatment Estimate
"¿Cuánto costará?"
│
Paciente acepta
│
▼
Se realizan prestaciones
│
▼
Invoice
"¿Qué se cobró?"
¿Es obligatorio tener las cuatro entidades?
No necesariamente.
Para un software odontológico pequeño o mediano, una arquitectura muy razonable sería:
Odontograma
│
▼
Presupuesto
│
▼
Factura
En ese diseño, el plan de tratamiento no existe como entidad independiente: el propio odontograma contiene los tratamientos indicados, y el presupuesto se genera seleccionando algunos o todos ellos.
De hecho, muchos sistemas odontológicos funcionan así. Separar Treatment Plan como entidad propia cobra más sentido cuando se necesita soportar planes alternativos, revisiones de planes o flujos clínicos más complejos. Si tu objetivo es mantener Dentalia simple pero bien diseñado, podrías empezar con Odontograma → Presupuesto → Factura y extraer un TreatmentPlan más adelante sólo si aparecen requisitos que realmente lo justifiquen.
¿Esto que estoy haciendo de presupuesto se llama funcionalidad, módulo, o cómo?
Depende del nivel del que estés hablando en la arquitectura del sistema.
Funcionalidad (feature): es el término más general. Desde el punto de vista del usuario, "hacer un presupuesto" es una funcionalidad.
Módulo (module): es un conjunto de funcionalidades relacionadas que forman una parte identificable del sistema. Si tu sistema tiene menú lateral con "Pacientes", "Turnos", "Odontograma", "Presupuestos", "Facturación", entonces Presupuestos es un módulo.
Submódulo: si el módulo de Presupuestos luego incluye, por ejemplo, "Plantillas", "Listas de precios", "Presupuestos" y "Aprobaciones", cada uno podría considerarse un submódulo.
Caso de uso (use case): desde el análisis de requisitos, "Generar presupuesto" o "Aceptar presupuesto" son casos de uso.
En tu proyecto Dentalia, yo lo describiría así:
Módulo: Presupuestos
Funcionalidades:
- Generar presupuesto desde el odontograma.
- Editar presupuesto.
- Recalcular precios.
- Imprimir presupuesto.
- Enviar presupuesto por e-mail.
- Registrar aceptación o rechazo.
- Convertir presupuesto en factura.
Así mantenés una terminología consistente:
Odontograma → módulo.
Presupuestos → módulo.
Facturación → módulo.
Pacientes → módulo.
Y dentro de cada uno, sus respectivas funcionalidades.
Es una forma de organizar el sistema que resulta clara tanto para la documentación como para la planificación del desarrollo.
No hay comentarios:
Publicar un comentario