- Rol
- Producto, frontend y backend
- Años
- 2025–
- Stack
- React · TypeScript · Go · PostgreSQL · Redis · AWS
- Código
- Privado
Clineo
Software de expediente clínico para consultorios en México. La meta es que el médico termine un expediente correcto y conforme a la norma durante la consulta, sin que el software le estorbe.
El problema
En México el expediente clínico está regulado. La NOM-004 dice qué debe contener, que una nota firmada ya no puede cambiar y que el expediente se conserva al menos cinco años. La NOM-024 pone reglas a los sistemas que lo guardan: identidad, acceso, trazabilidad, seguridad.
La mayoría de las herramientas lo tratan como papeleo para después. Clineo lo mete en el flujo de trabajo: el médico ve lo que la norma todavía pide mientras escribe, y las reglas que nunca deben romperse las aplica el sistema, no la buena voluntad.
Qué hace
Pacientes, agenda con reservas públicas, notas clínicas estructuradas con plantillas, signos vitales, consentimientos, documentos y archivos. Médicos, enfermería y asistentes tienen cada uno la navegación y el acceso que su rol necesita. Un panel de administración cubre cumplimiento y bitácora de auditoría.
Decisiones
Cumplimiento medido mientras se escribe
Cada nota muestra su completitud según la NOM-004 y los campos que faltan, sección por sección. El mismo cálculo se agrega por paciente y por médico en las vistas de cumplimiento.
Una nota firmada es definitiva
Cada médico tiene un par de llaves Ed25519; la semilla privada se guarda envuelta por KMS. La firma cubre el SHA-256 de una forma canónica de la nota, se hace con passkey, y un trigger de la base de datos rechaza cualquier cambio a una nota firmada.
Cifrado por paciente
Los datos personales y clínicos se cifran en la aplicación con AES-256-GCM, con una llave por paciente generada y envuelta por KMS. Las llaves en caché nunca quedan en claro en Redis.
Reglas que aplica la base de datos
Lo que no debe cambiar se protege con permisos de Postgres: la bitácora de auditoría solo acepta inserciones, en las tablas clínicas no se puede borrar (solo borrado lógico) y las llaves de firma se escriben una sola vez.
El administrador nunca ve pacientes
Los administradores no tienen acceso a pacientes y el módulo de administración no puede descifrar. Cuando tiene que referirse a un paciente, solo recibe un identificador opaco.
Una superficie pública aislada
Las rutas anónimas, como las reservas públicas, corren en un binario aparte. Una prueba falla si enlaza código clínico, y su rol de base de datos solo puede leer columnas concretas e insertar solicitudes que no puede volver a leer.
Una instancia por clínica
Cada clínica tiene su propia base de datos, caché, pool de identidad, llave de cifrado y bucket. Nada se comparte, así que no hay columna de tenencia que pueda fallar.
La IA solo extrae
La IA ayuda a estructurar y resumir lo que el médico escribió o dictó. Nunca diagnostica ni agrega información, y nada generado entra al expediente sin la firma del médico.
Cómo está hecho
El backend es un monolito modular en Go: un proceso sirve la API autenticada, cada módulo conserva su router y sus fronteras, y la superficie pública corre aparte. Cada decisión de arquitectura queda escrita; van 25 registros de decisión.
Frontend y backend se ponen de acuerdo con contratos escritos: el frontend nunca inventa un endpoint, y un script revisa que cada endpoint de un contrato exista en las rutas del backend. Snapshots de rutas, pruebas de integración contra un AWS local y pruebas end-to-end con Playwright cubren cada cambio.