Caso · sistema a medida

Veinte módulos alrededor de la agenda del día

Un centro de terapias con varias sedes: pacientes, sesiones, especialistas, camillas, cobros con comprobante electrónico y personal. El sistema tiene veinte módulos, pero hay uno que se mira cada hora, y todo lo demás existe para que ese esté al día.

Por qué aquí no hay una demo que puedas abrir

Es el sistema con el que un cliente trabaja todos los días, con datos de pacientes dentro. No hay versión pública ni la va a haber. Lo que se enseña son capturas de una instancia levantada aparte, con la marca sustituida, un RUC de ejemplo y pacientes, especialistas y contactos generados por los datos de prueba del propio proyecto: nadie de ahí existe.

Agenda del día con una columna por especialista, su horario y las sesiones colocadas en su franja — **La agenda del día es el corazón del sistema.** Una columna por especialista y la sesión en su franja, con la sede arriba. Se puede mirar por especialista, por camilla o por paciente, comparar lo *planificado* con lo *real* y apretar o soltar la densidad de la rejilla, porque no es lo mismo revisar el día en recepción que a media mañana.

Pantalla de emisión de comprobante electrónico con validaciones — Emisión del comprobante. Abajo, una lista de comprobaciones que se pone en verde mientras se llena: **hasta que no están todas, no se emite**. Un comprobante mal emitido cuesta una nota de crédito y una llamada.

Tablero de asesorías con el embudo de contactos y sus métricas — Quien contesta el teléfono y quien atiende son el mismo equipo: el embudo de contactos vive dentro del sistema, no en una hoja aparte.

Portada del sistema con sus módulos agrupados por área — Los módulos, agrupados por área: pacientes, programación, paquetes, inventario, botica, recepción, facturación, recursos humanos, proyectos. **Veinte piezas que se usan de verdad**, no un menú de intenciones.

Cómo está construido

Backend en Django corriendo sobre ASGI con Daphne y Redis detrás, PostgreSQL, y el frontend como aplicación aparte que habla con la API.

Django
ASGI · Daphne
Redis
PostgreSQL
Docker
nginx

Lo que se aprende al sacar un sistema de la red donde nació

Para tomar estas capturas hubo que levantarlo entero fuera de la infraestructura del cliente. Nada de esto se ve hasta que lo intentas, y es exactamente lo que separa un sistema que se puede mover de uno que no:

Los nombres de máquina con guion bajo no son dominios válidos, y Django rechaza esa cabecera. El error que sale parece de credenciales y no tiene nada que ver.
El arranque dependía de variables que ya no se usan: una base heredada y un servicio de imágenes externo. Sin ellas el sistema no levantaba, aunque no hicieran falta para nada.
La configuración del servidor traía direcciones fijas de la red del cliente y certificados suyos, así que fuera de allí no arrancaba ni el proxy.

Ninguna de las tres es un fallo grave en producción y todas son una tarde perdida cuando hay que migrar, hacer una copia de seguridad que se pueda restaurar o enseñárselo a alguien.

¿Tienes un sistema así, o lo estás pidiendo?

Sistemas de gestión a medida que aguantan el día a día de un negocio, con la parte aburrida hecha: permisos, comprobantes válidos y datos que cuadran.

Hablemos →