Volver al portfolio
Case Study
01 · 2024SaludEn producción

Sistema de Gestión de Informes Médicos

Informes médicos digitales, plantillas reutilizables, portal de pacientes 24/7.

Rol
Fullstack · Análisis · Arquitectura · Deploy
Período
2024 – Presente
Equipo
Solo developer + radióloga
Año
2024
80%
menos tiempo por informe
15 min → 3 min
24/7
portal pacientes
Sin desplazamientos
0
documentos perdidos
Trazabilidad total

Una radióloga con 40+ plantillas Word dispersas y pacientes sin acceso digital.

El cliente es una médica especialista en diagnóstico por imagen. Su flujo de trabajo dependía de documentos Word duplicados, archivos guardados en una sola PC y entrega de resultados en mostrador. Los informes tardaban, los pacientes esperaban y cualquier fallo de hardware podía significar perder el historial completo.

  • Sin trazabilidad de versiones ni firma verificable.
  • Pacientes sin acceso digital a estudios previos.
  • 10–20 minutos por informe escribiendo estructura que siempre era la misma.

3 fricciones costosas, todos los días.

01

Tiempo del profesional

15 minutos promedio por informe, mayormente formateando estructura repetitiva, no diagnosticando.

02

Acceso del paciente

Entrega solo presencial en horario administrativo. Si el paciente necesitaba el informe a las 21hs o un fin de semana, esperaba.

03

Integridad documental

Archivos en una sola PC local. Sin backup, sin historial ordenado, sin firma verificable.

Qué no se podía romper.

A.Continuidad

El equipo no podía parar de operar durante la transición al nuevo sistema.

B.Seguridad

Datos de salud: auth fuerte, URLs no-públicas, cookies HTTPOnly, RBAC por endpoint.

C.Costo

Operación mensual baja: stack pago-por-uso, S3 con URLs firmadas de TTL corto.

D.Curva de aprendizaje

El panel debía ser usable por la médica sin training previo. UX simple, 0 terminología técnica.

Qué se construyó.

Plataforma fullstack con panel médico, plantillas reutilizables, generación de PDFs con firma digital, portal de pacientes con acceso 24/7 y dashboard administrativo.

El producto en producción.

Panel de gestión médica
Vista principal del sistemaVista principal del sistema
Dashboard médicoDashboard médico
Gestión de plantillasGestión de plantillas
Lista de informesLista de informes
Generación de PDFs

El informe se genera en el servidor con pdfmake: firma digital incrustada, número de protocolo y datos del paciente. Descargable directamente desde el portal.

Ejemplo de informe generado — PDF con firma digitalEjemplo de informe generado — PDF con firma digital

Stack moderno, pragmático, mantenible.

Cliente MédicoNext.js · ReactCliente PacientePortal 24/7AdminDashboardNestJS APIJWT · Guards RBACPrisma + PostgreSQLPacientes · InformesAWS S3 (signed URLs)PDFs · Adjuntospdfmake · firma digitalGeneración on-demand
Entry pointsServicios internos
Frontend
  • Next.js (App Router)
  • React 18
  • TypeScript
  • Tailwind
  • Zustand
  • Zod
Backend
  • NestJS
  • Prisma ORM
  • PostgreSQL
  • JWT + Cookies HTTPOnly
  • Guards RBAC
Storage
  • AWS S3
  • Signed URLs (TTL corto)
  • pdfmake
Seguridad
  • reCAPTCHA en login
  • Rate limit
  • Audit log
  • Verificación SMS

Tres decisiones que se sostienen seis meses después.

A·01

NestJS para el backend, no Express puro

El sistema tiene múltiples entidades (pacientes, informes, plantillas, tipos de estudio, médicos) con relaciones entre sí. Necesitaba Guards, Pipes e Interceptors sin armarlos desde cero.

Elegido
NestJS con inyección de dependencias
Razón
Estructura modular nativa, decoradores para RBAC, escalable sin deuda técnica.
A·02

S3 con URLs firmadas, no buckets públicos

Los PDFs médicos son datos sensibles. Ningún archivo debe tener URL pública ni predecible.

Elegido
Pre-signed URLs con TTL de 15 min
Razón
Auth en la app + acceso temporal al asset. URL filtrada o guardada en historial se invalida sola.
A·03

Auth con cookies HTTPOnly, no localStorage

Datos de salud con múltiples roles. El riesgo de XSS en localStorage no era aceptable.

Elegido
JWT en cookie HTTPOnly + reCAPTCHA en login
Razón
Cookies HTTPOnly son inaccesibles desde JavaScript. Inmune a ataques XSS que intentan robar tokens.

Lo que no estaba en el plan.

  1. Modelo de plantillas con campos dinámicos. Cada tipo de estudio (radiografía vs. ecografía vs. TAC) tiene estructura diferente. Diseñé el schema con TemplateField que soporta tipos text, date, number, select — el médico crea variantes sin pasar por código.
  2. PDF con firma digital generado en el servidor. Usé pdfmake en el backend de NestJS para generar el PDF completo server-side, embebiendo la imagen de firma como base64. El documento clínico final no requiere post-procesamiento manual.
  3. Acceso público por token único sin cuenta de paciente. El médico puede compartir un informe con un link — el paciente lo abre sin registrarse. Implementé tokens de un solo uso con TTL configurable que se invalidan después de N usos o X tiempo.

Lo que cambió, medido.

Tiempo por informe
Antes
15 min
Ahora
3 min
Acceso del paciente
Antes
Solo presencial
Ahora
24/7
Integridad documental
Antes
Archivos en desktop
Ahora
Centralizado + auditado
Carga operativa
Antes
Cuello de botella en recepción
Ahora
0 entregas físicas

Lo que me llevo para el próximo proyecto.

  1. Empezar siempre con el flujo de salida (el PDF firmado) y modelar hacia atrás. Cuando el final está claro, el resto se ordena.
  2. El cliente médico no quiere features: quiere menos clicks. Cada feature nueva tenía que reducir tiempo en pantalla, no agregarlo.
  3. La seguridad no es el final del proyecto. Cada decisión de auth, storage o logs abre o cierra puertas que cuestan 5x arreglar después.
Siguiente

¿Querés un proyecto así para tu producto?

Respondo en menos de 24 hs hábiles. Cuanto más concreto el contexto, más rápido te digo si encaja.