Proyecto · Salud digital

ClinIA: historia clínica electrónica

Un mismo paciente puede ser atendido por varios médicos de distintas instituciones, y su historial lo sigue sin que nadie tenga que pedirlo por teléfono. El historial es del paciente, no del consultorio.

FastAPIPythonPostgreSQLReact 19TailwindCSSJWTDocker
Pantalla de la historia clínica electrónica ClinIA

El problema

En Perú, la historia clínica de un paciente vive partida en tantos sistemas como consultorios haya visitado. Cuando llega a uno nuevo, el médico empieza de cero: vuelve a preguntar alergias y vuelve a pedir exámenes que ya existen.

ClinIA parte de un registro único de paciente. Un médico ve lo que el paciente le ha autorizado ver, y esa autorización es explícita y revocable.

Mi rol

Arquitectura y decisiones técnicas del proyecto: el modelo de registro único, el control de acceso por rol en el servidor y la migración de Supabase a PostgreSQL directo.

Arquitectura de ClinIA Cuatro roles entran por un frontend React. Cada petición lleva un JWT y llega a FastAPI, donde un decorador require_role comprueba el permiso en el servidor antes de tocar PostgreSQL. Usuariosmédico · enfermeríapaciente · adminHTTPSFrontendReact 19Radix · TailwindJWTAPIFastAPIrequire_role()SQLPostgreSQLregistro únicode paciente
Arquitectura de ClinIA

Roles y alcance

RolQué puede hacer
SuperadministradorPlataforma, instituciones, médicos y métricas
MédicoSus pacientes: historia, consultas, exámenes, citas y recetas
EnfermeríaTriaje y signos vitales
PacienteSu propia historia, sus citas y sus resultados

Decisiones de diseño

  • Los permisos se comprueban en el servidor. Un decorador require_role() sobre cada ruta. Una interfaz que esconde un botón no es control de acceso: el endpoint tiene que negarse aunque alguien lo llame directo.
  • De Supabase a PostgreSQL directo. Supabase resolvía rápido la autenticación, pero ataba el esquema y las políticas a un proveedor. Para datos clínicos esa dependencia era un riesgo mayor que la comodidad. Cómo se hizo la migración sin reescribir el backend.
  • Los enums en un solo módulo. Estados, roles y tipos de examen en un único sitio, para que no acaben conviviendo «pendiente», «PENDIENTE» y «en_espera».

Qué hace

  • Registro único de paciente con identificador interno
  • Historia clínica: antecedentes, alergias y medicación habitual
  • Consultas con triaje y signos vitales
  • Exámenes y resultados, citas con calendario, recetas con plantillas
  • Historial compartido entre médicos autorizados por el paciente

Limitaciones conocidas

  • La transcripción de voz y el asistente clínico están en la interfaz pero todavía no tienen motor detrás.
  • No tiene certificación normativa para uso clínico real en Perú.
  • Compartir historial está resuelto a nivel de permisos, no de interoperabilidad: no habla HL7 ni FHIR. Es el siguiente paso lógico.
El CV estará disponible próximamente.