Volver
Año
2026
Tecnologías
Java, Spring Boot, React, TypeScript, Vite, Tailwind CSS, PostgreSQL, Supabase
Descripción
El problema. En un hospital, un dato inconsistente no es un bug: es una habitación asignada a dos pacientes o una internación duplicada. El desafío fue modelar un dominio clínico real —pacientes, fichas médicas, internaciones, historiales— garantizando integridad y trazabilidad en cada capa, no solo en la interfaz.
Decisiones y por qué. Modelamos el dominio en un esquema PostgreSQL de 25 tablas normalizadas, con ENUMs para valores cerrados (tipos de sangre, sexo) y timestamps de auditoría. Elegimos baja lógica (deleted_at) en lugar de DELETE físico: en salud, borrar un paciente destruye trazabilidad para auditorías médicas. Los DTOs desacoplan la API de las entidades JPA —nunca se serializa usuario.pass ni relaciones lazy accidentales. Aplicamos el patrón Builder para construir agregados complejos como Paciente (persona + domicilio + ficha médica + obra social + contactos) sin constructores de 15 parámetros. La seguridad es de doble capa: Spring Security + JWT en backend, rutas protegidas por rol en el frontend — el frontend oculta, el backend rechaza con 403.
Una decisión de la que estoy orgulloso. No hay registro público: el alta de usuarios es solo por invitación con token y expiración, con roles asignados por el admin, contraseñas temporales con cambio obligatorio en primer login, y un superadmin protegido que ni siquiera otro administrador puede desactivar. Es el modelo de acceso que un sistema de salud real necesita.
Resultados. 6 módulos funcionales (pacientes, habitaciones/internaciones, historial clínico con timeline, administración, auth, perfil), ~35 endpoints REST, mapa de 40 habitaciones en 7 pisos con internar/trasladar/egresar que registra eventos clínicos automáticos, seed realista de 50 pacientes y +500 registros clínicos, tests de integración en backend. Desarrollado en equipo de 2 con Scrum (5 sprints), casos de uso, diagramas de secuencia y diccionario de datos completo.
Decisiones y por qué. Modelamos el dominio en un esquema PostgreSQL de 25 tablas normalizadas, con ENUMs para valores cerrados (tipos de sangre, sexo) y timestamps de auditoría. Elegimos baja lógica (deleted_at) en lugar de DELETE físico: en salud, borrar un paciente destruye trazabilidad para auditorías médicas. Los DTOs desacoplan la API de las entidades JPA —nunca se serializa usuario.pass ni relaciones lazy accidentales. Aplicamos el patrón Builder para construir agregados complejos como Paciente (persona + domicilio + ficha médica + obra social + contactos) sin constructores de 15 parámetros. La seguridad es de doble capa: Spring Security + JWT en backend, rutas protegidas por rol en el frontend — el frontend oculta, el backend rechaza con 403.
Una decisión de la que estoy orgulloso. No hay registro público: el alta de usuarios es solo por invitación con token y expiración, con roles asignados por el admin, contraseñas temporales con cambio obligatorio en primer login, y un superadmin protegido que ni siquiera otro administrador puede desactivar. Es el modelo de acceso que un sistema de salud real necesita.
Resultados. 6 módulos funcionales (pacientes, habitaciones/internaciones, historial clínico con timeline, administración, auth, perfil), ~35 endpoints REST, mapa de 40 habitaciones en 7 pisos con internar/trasladar/egresar que registra eventos clínicos automáticos, seed realista de 50 pacientes y +500 registros clínicos, tests de integración en backend. Desarrollado en equipo de 2 con Scrum (5 sprints), casos de uso, diagramas de secuencia y diccionario de datos completo.