Klinex habla con clientes Redis/Valkey, pero no hereda su modelo. Está pensado para estado clínico estructurado: tipos nativos, TTL semántico, índices de dominio, invalidación por evento y auditoría append-only.
Klinex se ubica entre las capas de integración —API gateways, routers HL7/FHIR, motores conversacionales— y los servicios que consumen estado clínico. Hace una cosa y la hace con semántica de dominio.
No competimos por ser el GET/SET más genérico. El valor está en alta cardinalidad, claves compuestas, estado durable, auditoría y consultas de dominio.
clave opacaExcelente para cache efímero y estructuras simples.TTL numéricoExpira por segundos, no por intención clínica.cluster slotsDistribución rápida, sin consenso fuerte por operación.observabilidadMétricas de sistema; poca historia semántica del dato.tipo + índiceHL7, FHIR, pacientes, sesiones y slots se consultan por campos reales.TTL semánticoAlta, confirmación, cambio de estado o cierre de sesión invalidan el dato.Raft futuroEl diseño apunta a quorum, failover y lecturas con consistencia configurable.audit trailCada escritura clínica deja huella encadenada por hash.Cada tipo determina qué se indexa, qué eventos lo invalidan y cómo se interpreta su estado semántico. Diseñado para cualquier clínica u hospital: el identificador de paciente admite RUT, MRN, identificador FHIR, DNI extranjero o pasaporte.
Identificado por 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 ligado.
Hoy el core mantiene un índice invertido por TIPO|campo=valor. Para superar
a Redis en cargas tipo Momentic, el siguiente paso es un índice compuesto durable:
resolver primero el mejor estado/version/commit disponible y recién después leer
las entradas exactas.
HL7_MSG|paciente_id=... apunta a claves vivas en el shard dueño.
tenant + tipo + branch + version + timestamp reduce búsquedas masivas.
Precalcular timestamps/estados disponibles evita escanear la tabla grande.
Extender vida por reinserción y deduplicar en background, sin UPDATE caliente.
Lectura objetivo: buscar por clave clínica compuesta, elegir la versión válida más cercana y devolver el payload sin depender de un scan ni de un TTL ciego.
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 ocurre el evento publicado.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, solo como red de seguridad.Texto sobre TCP para control y depuración; binario con framing por longitud para producción. La identidad es obligatoria: sin actor no hay auditoría, y sin auditoría no hay escritura.
Cada SET, DELETE e INVALIDATE encadena su hash con el de la operación previa. Alterar un registro pasado invalida todos los posteriores.
Los sistemas externos 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.
Sin GC, sin unsafe salvo justificación. Binario estático musl
de ~1.6 MB, listo para desplegar en cualquier host Linux.