Habla RESP como Redis/Valkey, pero entiende salud: tipos nativos HL7 / FHIR, TTL que es una condición y no un número, invalidación por evento, colas de trabajo con reintentos y auditoría encadenada que sobrevive a la caída.
Klinex se ubica entre las capas de integración —API gateways, routers HL7/FHIR, motores conversacionales— y los servicios que consumen estado clínico. Cualquier cliente Redis se conecta; los que conocen Klinex aprovechan la semántica de dominio.
Cada tipo determina qué se indexa, qué eventos lo invalidan y cómo se lee su estado. Diseñado para cualquier clínica u hospital: el identificador de paciente admite RUT, MRN, FHIR, DNI extranjero o pasaporte.
RUT, MRN, FHIR, DNI o pasaporte. Indexado para búsqueda directa.
Máquina de estados conversacional para motores LLM y WhatsApp.
Mensaje HL7 v2 crudo, con headers MSH, PID y PV1 indexados.
Recurso FHIR R4, consultable por resourceType e identifier.
Unidad de agendamiento con transiciones de estado explícitas.
Alerta clínica con severidad; expira al confirmarse el evento.
Un mensaje de admisión no "expira en 3600 segundos": deja de ser válido cuando llega el alta, o cuando el slot pasa a CONFIRMADO. Klinex modela la intención clínica real.
HASTA_EVENTO <evento>Se invalida cuando se publica el evento.HASTA_ESTADO <tipo> <estado>Se invalida cuando el recurso alcanza ese estado.HASTA_CONFIRMACIONSe invalida con un ACK explícito.VENTANA_SESIONLigado al turno conversacional activo.HASTA_TIMEOUT <seg>Fallback numérico, sólo como red de seguridad.
Comandos estándar sobre el namespace genérico; comandos K*
para la semántica clínica con auditoría. La identidad se verifica
contra el catálogo —no se afirma— y sin ella no hay escritura clínica.
Recibir un mensaje y ejecutar un procedimiento contra Oracle o SAP son dos
cosas distintas. Si el destino está degradado, el mensaje no se pierde ni
retiene el hilo: se encola con un retardo y se reintenta. Entrega
at-least-once, deduplicada por MSH-10.
KPUSH <cola> <payload> ID <msh-10>El mismo mensaje reenviado no se encola dos veces.… DELAY <ms> · PRIO <0-9>Retardo y prioridad a la vez: son dos índices, no un score.KPOP <cola> [COUNT <n>]Entrega con plazo de confirmación; sin ACK, vuelve a la cola.KACK · KNACK · KREJECTConfirmar, reintentar con backoff, o descartar sin gastar intentos.KQDEAD <cola>Lo que agotó sus reintentos, con el payload intacto.La receta clásica sobre Redis mete ambas en un mismo score y obliga a elegir cuál se respeta. Aquí son dos índices con un paso de promoción: el diferido no sale antes de tiempo y el urgente no espera detrás.
Sacar de la cola y marcar como no confirmado ocurren dentro de la tarea que posee la cola. No hay nada que hacer atómico: no se emula una cola sobre estructuras genéricas, la cola es del motor.
Al agotar los intentos el mensaje no se borra: pasa a la cola de muertos con su payload. Un HL7 que falló cinco veces y se evapora es justo el fallo que esto existe para evitar.
Ingreso, duplicado detectado, entrega perdida, devolución y muerte entran al audit trail encadenado. Saber que el origen reenvió el mismo mensaje es exactamente lo que un canal opaco no te dice.
El catálogo es la única fuente de verdad, y el motor lo reconcilia:
lo que está vivo y no está declarado se elimina. No hay forma de mutarlo por
protocolo — KCATALOG
sólo lee. La ausencia de declaración es denegación, no permiso.
El token se comprueba contra el token_sha256 declarado, y
el servicio que llega al audit trail sale de la declaración,
no de la conexión. Con mTLS es la huella del certificado y no viaja
ningún secreto.
Permisos separados para leer, escribir, usar colas, publicar, suscribirse y auditar. Un actor sin declaración no hace nada, y quitarlo del archivo revoca sus sesiones abiertas sin reiniciar.
Cargar un archivo es una convención; reconciliarlo es una garantía. El loop compara lo declarado con lo vivo y elimina lo que sobra, así que el archivo no puede quedar mintiendo.
Cada cambio del catálogo entra al audit trail. Saber quién tocó una ficha sirve de poco si no consta quién cambió las reglas que decidían quién podía tocarla.
Cada SET, DELETE e INVALIDATE encadena su hash SHA-256 con el de la operación previa. Alterar el pasado invalida todo lo posterior.
kill -9Audit trail y colas se persisten con framing CRC32 en logs separados; al arrancar se reproducen y toleran truncamiento por caída. Sin reinicios manuales.
Un KPUSH no responde hasta que el mensaje está
persistido: es la diferencia entre «acepté tu HL7» y «acepté tu HL7 y no
lo voy a perder». Tras una caída dura, lo confirmado no revive y lo que
estaba en vuelo se re-entrega conservando sus intentos.
Los sistemas publican eventos por el canal pub. Sin polling, sin escaneos lazy de expiración sobre tipos clínicos.
Un thread por shard, modelo actor sobre Tokio. El estado no se comparte: se accede por mensajes. El log vive en un shard aparte.
Un binario estático de ~2 MB. Habla RESP. Entiende salud. Y no pierde mensajes.