Redis Real-Time Decisioning Demo | Healthcare Access Steering

Stage 1: The Architecture

RiverHealth Access's Real-Time Decisioning Stack

Five tiers form a continuous loop: ingest, context, decide, act, learn. The best action is not always the next open slot. It is the safest, fastest, and most cost-effective path for this patient now. Systems of record stay where they are. Redis becomes the operational context layer that makes the moment actionable.

Data Sources

EHR / Scheduling

Operational source

Eligibility and Benefits Platform

Operational source

Nurse Triage Engine

Operational source

Provider Directory APIs

Operational source

Capacity / Bed Management

Operational source

Kafka / Digital Front Door Events

Operational source

Ingest Layer

Redis Data Integration (RDI)

CDC from repositories and operational databases with sub-second activation

Redis Feature Form + Streams

Feature serving and live event hydration from Kafka, Redis Streams, and industry APIs

Unified Context Layer

Redis RAM

Hot appointment state, active eligibility signals, live provider capacity, and urgent care flags

Redis Flex

Warm patient history, care pathway embeddings, prior authorization context, and network utilization

Feature Store

Access urgency, no-show risk, network fit, and care navigation features

Redis Context Retriever

Assembles the Member 360 — care state, plan history, and access context — and exposes it as structured MCP tools for the decision engine

Decision Engine

Eligibility Rules

Policy, compliance, and inventory constraints

NBA Ranker

Contextual ranking weighted by value, risk, and fit

Policy Arbitration

One action selected for the current moment

Output Channels (Act)

Patient Portal

Customer-facing activation surface

Call Center Desktop

Customer-facing activation surface

Mobile App

Customer-facing activation surface

SMS / Email

Customer-facing activation surface

↺

Learn: Decision logs and outcomes stream back into model training, policy updates, and the Redis context layer.

Decision latency

16.2 ms

In-network steer rate

+17 pts

Avoidable ED reduction

-12%

Stage 2: Trigger Event

Marcus Green creates a decision moment

A patient searches for care after symptoms worsen and appointment capacity is tight. Steer to the right site of care using symptoms, benefits, provider availability, and operational load.

Live Trigger

Marcus Green

Established patient | PPO coverage | evening access search

HEALTH

Eventcare_search_started

Customer surfacePatient portal

Decision objectiveRight-site care + leakage reduction

Decision windowBefore the surface finishes rendering

Context requiredHistory + live signals + policy

Business stakes+17 pts

Why This Moment Matters

The best action is not always the next open slot. It is the safest, fastest, and most cost-effective path for this patient now.

Without Redis: the application waits on siloed repositories and defaults to a generic next step.

With Redis: the decision surface opens with ranked, contextual action already staged for the moment.

Stage 3: Ingest

Industry repositories and streams flow into Redis

These are common repositories and streaming APIs for healthcare decisioning. They remain the systems of record. Redis activates the working set needed to decide now.

Redis Data Integration (RDI)Redis Feature Form

Source Systems → Redis

EPIC

Epic / Cerner

Common repository or streaming source for epic context

→

SCHE

Scheduling APIs

Common repository or streaming source for scheduling context

→

ELIG

Eligibility engine

Common repository or streaming source for eligibility context

→

PROV

Provider directory

Common repository or streaming source for provider context

→

KAFK

Kafka / Redis Streams

Event streaming via Kafka or Redis Streams — no separate broker required with Redis Streams built-in

→

TRIA

Triage and symptom APIs

Common repository or streaming source for triage context

→

Ingest Pipeline Status

CDC modeReal-time

Streaming lag<100 ms

Feature parityTrain = serve

Custom sync code0 lines

Serving roleOperational context layer

Stage 4: Context Assembly

History and live state converge into one working view

Redis assembles profile history, patient or member state, live intent, and policy constraints in one low-latency lookup path. What looked like a simple event in Stage 2 becomes a much richer decision moment here.

Redis RAMRedis FlexRedis Context Retriever

Historical Context

Customer value band12 min

Tenure / relationship depthEstablished

Prior interaction patternKnown baseline available

Eligibility stateResolved in memory

Policy constraintsCurrent and active

Action historyFrequency caps enforced

Live Context

Current intentRight-site care + leakage reduction

Streaming signal stateFresh for this session

Capacity / inventoryAvailable

Risk / complianceWithin active rules

Surface readinessPatient portal

Decision scopeVirtual urgent care same evening

Key insight: Redis Context Retriever assembles the Member 360 — care state, plan history, and access context — so the decision engine has exactly what it needs. The winning action becomes obvious only when historical context and live signals appear in the same response path.

Stage 5: Feature Serving

Online features hydrate the ranker in milliseconds

Redis Feature Form serves model-ready signals from Redis with train-serve parity. No fan-out calls to downstream systems during decisioning. No stale fallbacks.

Redis Feature FormRedis Feature Store

symptom_urgency

Real-time feature served from Redis with train-serve parity.

moderate0.3 ms

benefit_fit

Real-time feature served from Redis with train-serve parity.

in-network0.4 ms

provider_capacity

Real-time feature served from Redis with train-serve parity.

available0.5 ms

travel_time

Real-time feature served from Redis with train-serve parity.

12 min0.6 ms

leakage_risk

Risk and policy factor used to gate the action.

elevated0.7 ms

triage_confidence

Real-time feature served from Redis with train-serve parity.

0.900.8 ms

Feature Serving Performance

Features Hydrated

186

P99 Lookup Latency

<20ms

Train / Serve Parity

100%

Stage 6: Ranking

Candidate actions are ranked for this moment

Rules, policies, vector similarity, and business weighting combine to rank the best action now. The winner is selected because it fits the moment, not because it is the easiest generic fallback.

Redis SearchNBA RankerRules Engine

#1 Winner

PRIMARY ACTION

Virtual urgent care same evening

Clinically appropriate with in-network availability

NBA score0.94

#2 Candidate

ALTERNATIVE

Primary care next-day visit

Acceptable but slower and more likely to drive external leakage

NBA score0.79

Suppressed

POLICY

ED recommendation

Suppressed because symptoms and triage score do not warrant it

Suppressed0.24

Stage 7: Business Impact

The value of choosing the right action now

Fast decisions matter, but the real value is choosing the right action while the moment is still open. Redis improves both latency and outcome quality.

Decision Economics

Decision latency16.2 ms

In-network steer rate+17 pts

Avoidable ED reduction-12%

The key insight: value compounds when the decision surface uses live operational context instead of generic fallback logic.

Moment Outcome

Generic

Siloed systems
lower relevance

→

Redis

Context-aware
higher impact

Stage 8: Outcome

Same surface. Different decision layer.

On the left is a generic or delayed path. On the right is the Redis-powered experience with ranked action already staged. Same customer moment. Different outcome.

Generic Experience

Marcus Green

Healthcare workflow

What the system knows

Partial profile, delayed retrieval, and limited live context.

Action shown

Primary care next-day visit

Outcome risk

The action fits broadly, but not the full moment.

Lower

relevance

Higher

fallback use

Siloed

context

Redis-Powered Experience

Marcus Green

Decision-ready profile

#1 Next Best Action

Virtual urgent care same evening

Clinically appropriate with in-network availability

Why it wins

Combines history, live signals, business value, and active policy constraints in the same low-latency response.

Visible impact

In-network steer rate: +17 pts.

High

relevance

Low

fallback use

Ready

before render

Stage 9: The Architecture, Proven

Architecture first. Architecture last. Outcome in the middle.

The same five tiers you saw at the start now tie directly to a measurable decision outcome. Common repositories and streaming APIs stay in place. Redis remains the operational decisioning layer that makes the customer moment work.

Data Sources

EHR / Scheduling

Operational source

Eligibility and Benefits Platform

Operational source

Nurse Triage Engine

Operational source

Provider Directory APIs

Operational source

Capacity / Bed Management

Operational source

Kafka / Digital Front Door Events

Operational source

Ingest Layer

RDI

CDC and activation from systems of record

Streams + Features

Live event hydration and model parity

Unified Context Layer

Redis RAM

Hot appointment state, active eligibility signals, live provider capacity, and urgent care flags

Redis Flex

Warm patient history, care pathway embeddings, prior authorization context, and network utilization

Feature Store

Access urgency, no-show risk, network fit, and care navigation features

Redis Context Retriever

Assembles the Member 360 — care state, plan history, and access context — and exposes it as structured MCP tools for the decision engine

Decision Engine

Rules

Eligibility, compliance, and policy

Ranker

Propensity, value, and fit

Arbitration

One action selected now

Output Channels

Patient Portal

Customer-facing activation surface

Call Center Desktop

Customer-facing activation surface

Mobile App

Customer-facing activation surface

SMS / Email

Customer-facing activation surface

↺

Learn: Outcomes feed retraining, policy updates, and future decisions without changing the systems of record.

Decision latency

16.2 ms

In-network steer rate

+17 pts

Avoidable ED reduction

-12%