Ya estuve diseñando el flujo de realización de tratamientos con cobro incluido. Tengo algunas ideas para contarte. Después del odontograma va a venir una pantalla de propuesta de tratamiento, que por cierto va a abarcar también lo que es aceptación de presupuesto. Después vendrá la pantalla de cobros. ¿Te cuento más en detalle lo que pienso hacer o te voy pidiendo directamente "haceme tal migración, tal página de inertia con tal y tal cosa..."?
Por todo lo que llevamos trabajando en Dentalia, te recomendaría contarme primero el flujo completo. Creo que eso te va a ahorrar retrabajo.
Ya pasó varias veces en este proyecto que, cuando conocimos el objetivo más amplio, terminamos cambiando alguna entidad o alguna API que inicialmente parecía correcta. Por ejemplo:
el documento JSON del odontograma terminó teniendo
schema_versionyrevision;la ruta de actualización pasó de
/api/odontograma/{odontograma}a/api/pacientes/{paciente}/odontograma;decidimos separar presupuesto de facturación;
decidimos hacer control de concurrencia optimista.
Si hubiéramos implementado cada pantalla aisladamente, probablemente habríamos tenido que rehacer varias cosas.
Lo que yo haría
Primero dedicaría una conversación (o varias) únicamente a diseñar el flujo.
Algo como:
Paciente
↓
Odontograma
↓
Propuesta de tratamiento
↓
Aceptación del paciente
↓
Cobro
↓
Facturación (opcional)
Y para cada paso responder preguntas como:
¿Qué puede hacer el usuario?
¿Qué entidades se crean?
¿Qué entidades se modifican?
¿Qué estados existen?
¿Qué restricciones hay?
¿Qué relaciones aparecen?
Sin escribir una línea de código.
Después
Recién ahí iría implementando módulo por módulo.
Por ejemplo:
Migraciones.
Modelos.
Policies.
Requests.
Controladores.
Rutas.
Páginas Inertia.
Componentes shadcn/ui.
Tests.
De esa forma casi no habría que volver atrás.
Hay algo más que me parece muy interesante
Creo que ya estás dejando de diseñar "pantallas" y empezando a diseñar un modelo de negocio para un consultorio odontológico.
Esa diferencia es importante.
Una pantalla puede cambiar diez veces.
El modelo de negocio (Paciente → Odontograma → Propuesta → Cobro...) debería permanecer estable durante años.
Por eso me entusiasma más dedicar tiempo ahora a discutir el flujo que escribir inmediatamente migraciones.
Una propuesta
Yo incluso haría un documento que se llame algo como:
Arquitectura funcional de Dentalia
No sería un documento técnico ni un manual de usuario.
Sería el relato completo del funcionamiento del consultorio dentro del sistema, siguiendo a un paciente desde su ingreso hasta la finalización del tratamiento y el cobro. A medida que aparezcan nuevos módulos (agenda, imágenes, obras sociales, inventario, etc.), se incorporan a esa misma historia.
Ese documento terminaría siendo la "fuente de verdad" del proyecto. Después, cuando me pidieras:
"Haceme la migración de PropuestaTratamiento"
yo ya conocería exactamente qué lugar ocupa en el flujo y qué responsabilidades tiene, en lugar de diseñarla de manera aislada. Creo que eso va a dar un resultado mucho más coherente para todo el sistema.
Si yo empiezo con todo el relato ¿Vos me vas a decir cuándo haya información suficiente para pasar a la siguiente etapa?
Sí. Me parece la mejor forma de trabajar.
Mientras vos vas relatando el flujo, yo voy actuando como un analista funcional y arquitecto de software. En cada etapa voy a distinguir entre tres casos:
"Todavía falta información."
Te haré preguntas concretas sobre los aspectos que faltan definir.
No avanzaremos al siguiente módulo hasta que el diseño de esa etapa sea suficientemente consistente.
"Ya está suficientemente definido."
Te diré explícitamente: "Con esta información ya podemos dar por diseñado este módulo y pasar al siguiente."
"Hay una decisión pendiente, pero no bloquea."
La anotaré como una decisión diferible y seguiremos adelante si no afecta al resto del diseño.
Además, mientras hablás, iré construyendo mentalmente (y cuando convenga, por escrito):
el flujo funcional;
las entidades del modelo de datos;
las relaciones entre ellas;
los estados y transiciones;
las reglas de negocio;
las APIs necesarias;
las páginas Inertia;
los componentes de shadcn/ui;
los permisos que eventualmente harán falta.
De esa manera, cuando terminemos el relato, no tendremos solamente una idea general: tendremos una especificación lo bastante sólida como para implementar el sistema casi de forma mecánica, módulo por módulo.
Creo que este enfoque encaja muy bien con la forma en que venís trabajando: primero buscás entender profundamente el dominio y recién después escribís código. Empecemos por el relato, y yo te iré indicando cuándo una etapa quedó cerrada y cuándo conviene pasar a la siguiente.
Primero estoy pensando si sería más acorde a la escala de mi proyecto tener una única entidad para plan de tratamiento y para presupuesto, algo como:
presupuestos
-------------
id
paciente_id
fecha
estado
subtotal
descuento
total
presupuesto_items
-----------------
id
presupuesto_id
prestacion_id
pieza
cantidad
precio_unitario
importe
Con esto me propongo representar el flujo de la siguiente manera:
Los tratamientos se guardan en el JSON del odontograma mediante un contenido como el siguiente:
"marcas_dentales": [
{ "codigo": "obturacion-pendiente", "casillero": 10, "superficie": 1, "incluir en presupuesto": false },
{ "codigo": "obturacion-pendiente", "casillero": 47, "superficie": 3, "incluir en presupuesto": true }
],
"soluciones": [
{ "tipo": "protesis", "casillero": 4, "incluir en presupuesto": true, "realizado": false },
{ "tipo": "extraccion", "casillero": 10, "incluir en presupuesto": true, "realizado": false },
{ "tipo": "perno-corona", "casillero": 11, "incluir en presupuesto": false, "realizado": false }
]
Los items que tienen "incluir en presupuesto" = true quedan seleccionados para ser incluidos en la siguientye etapa, el presupuesto, y en este sentido, forman parte del plan de tratamiento a proponer al paciente.
El flujo continúa en una pantalla de confección de propuestas. Allí habrá una lista de tratamientos que serán todos los items de "marcas_dentales" y "soluciones" del json. En cada fila de la lista de tratamientos en pantalla habrá un checkbox que estará marcado si sólo si el correspondiente ítem en el json tiene "incluir en presuspuesto" = true.
Esta pantalla tendrá los botones "Aceptar presupuesto" y "Rechazar presupuesto", puesto que la idea es que la pantalla en cuestión represente al mismo tiempo la confección del presupuesto y la decisión del paciente sobre si aceptarlo o rechazarlo.
Tanto si la respuesta es aceptar como rechazar el presupuesto, se generará la entidad "presupuestos" y "presupuesto_items" que te mostré más arriba. Que la respuesta haya sido de aceptación o de rechazo quedará registrada en el campo "estado" de la tabla "presupuestos".
Me gusta mucho más este nivel de conversación. Ahora ya estamos diseñando el dominio, y no simplemente tablas. Voy a ir comentando lo que veo.
Lo que me gusta
Hay una idea que me parece muy acertada: el plan de tratamiento no es una entidad persistente independiente, sino un estado del odontograma.
Es decir, el odontólogo trabaja sobre el odontograma, agrega marcas, soluciones, etc., y algunas de ellas pasan a formar parte de la propuesta económica mediante incluir en presupuesto.
Eso evita duplicar información.
Hasta acá me parece una muy buena decisión para un proyecto de la escala de Dentalia.
También me gusta unificar "plan" y "presupuesto"
Yo probablemente también lo haría.
En un consultorio odontológico pequeño, la conversación suele ser:
—Hay que hacer estas cinco cosas.
—¿Cuánto sale?
—Este es el presupuesto.
—Bueno, acepto.
No existen realmente dos documentos distintos.
Existe una única propuesta.
En ese sentido, la tabla
presupuestos
representa bastante bien esa propuesta.
El presupuesto pasa a ser una fotografía
Esto me parece importante.
Cuando el paciente acepta o rechaza, vos generás
presupuestos
presupuesto_items
Eso significa que el presupuesto es un snapshot del odontograma en ese momento.
Eso es muy bueno.
Porque luego el odontograma puede seguir cambiando.
Me gusta que el presupuesto sea inmutable
De hecho iría un paso más allá.
Una vez creado:
presupuesto.estado = aceptado
o
rechazado
yo ya no permitiría modificar sus ítems.
Si hay que cambiar algo:
Presupuesto 12 -> rechazado
↓
Presupuesto 13 -> pendiente
Eso deja un historial excelente.
No digo que debamos implementarlo ya, pero conceptualmente me gusta más.
Donde sí tengo una duda importante
Es esta.
Decís:
La pantalla tendrá los botones "Aceptar presupuesto" y "Rechazar presupuesto".
Mi pregunta es:
¿Quién confecciona el presupuesto?
Hoy el flujo parece ser:
Odontólogo
↓
arma la propuesta
↓
el paciente está presente
↓
acepta o rechaza inmediatamente
Eso ocurre muchas veces.
Pero también ocurre muchísimo esto:
Odontólogo
↓
arma presupuesto
↓
lo imprime
↓
el paciente dice
"Lo pienso y te aviso."
↓
dos semanas después llama
↓
"Acepto."
En ese escenario, la pantalla de confección ya no coincide con la aceptación.
Entonces quiero preguntarte si eso es una simplificación deliberada o si querés contemplar ambos casos.
Otra cosa que me llamó la atención
Los checkboxes viven en el JSON.
Eso significa que el JSON contiene información clínica y comercial mezclada.
Ejemplo:
obturación pendiente
es clínico.
Pero
incluir en presupuesto
es administrativo.
No digo que esté mal.
Pero quiero preguntarte:
¿Estás cómodo con que el odontograma conozca conceptos administrativos?
Porque es una decisión de arquitectura bastante importante.
Otra pregunta importante
Supongamos:
Extracción
está incluida en el presupuesto.
Luego el odontólogo decide:
"No.
En realidad vamos a hacer endodoncia."
¿Qué ocurre?
¿Se modifica el odontograma?
¿Se genera un nuevo presupuesto?
¿Se invalida el anterior?
Todavía no necesito la respuesta.
Solo la dejo anotada porque probablemente afecte el flujo.
Mi impresión hasta ahora
Creo que ya podemos dar por establecidos varios principios del diseño:
El odontograma es la fuente de verdad clínica.
El plan de tratamiento no existe como entidad separada.
El presupuesto es una fotografía (snapshot) del estado del odontograma.
El presupuesto tiene ítems propios y no depende del JSON una vez generado.
Eso me parece un diseño bastante limpio.
Pero todavía no daría por cerrado este módulo.
Antes quisiera resolver, al menos conceptualmente, estas dos cuestiones:
¿La confección del presupuesto y su aceptación son siempre el mismo acto, o pueden ocurrir en momentos distintos?
¿Qué pasa cuando cambia el tratamiento después de haberse emitido un presupuesto?
Creo que esas dos respuestas terminarán de definir si la entidad presupuestos ya está correctamente diseñada o si le falta algún estado o alguna regla de negocio.
No hay comentarios:
Publicar un comentario