Most healthcare data platforms run RAF scoring as a nightly batch job. A new diagnosis is documented in the EHR at 2pm — it appears in the risk score the following morning. By then, the care manager's window to act on it has already shifted.
Real-time RAF scoring changes the operational model: a new ICD-10 code hits the clinical data stream, the patient's RAF is recalculated in under 5 seconds, and the care gap is already in the provider worklist before the physician has finished their note.
This isn't just a latency improvement. It's a fundamentally different care management architecture.
The Problem with Nightly Batch RAF
Nightly batch scoring creates several operational failure modes:
Stale risk stratification. If a patient's condition worsens overnight — a new diagnosis from an after-hours urgent care visit — the care manager's risk tier doesn't update until tomorrow. High-risk outreach may be delayed by 24-48 hours.
Care gap staleness. A care gap that closes at 3pm (documentation of a completed mammogram, for example) still shows as open in the morning's worklist. Care managers spend time chasing gaps that no longer exist.
Missed coding opportunities. When a suspect HCC is identified by NLP extraction at 10am, the coder doesn't see it until the next morning's queue. In a high-volume coding operation, this compounds into significant pipeline lag.
Attribution drift. Member enrollment changes — a patient switches from one plan to another, or a dual-eligible member changes ESRD status — don't propagate to the risk model until the next batch run, potentially affecting payment calculations.
The Kafka CDC Architecture
Real-time RAF scoring requires a change data capture (CDC) pipeline, not just a faster batch schedule.
The architecture looks like this:
EHR / FHIR API → Bronze Ingest
↓
Silver Canonical Layer
↓
Kafka CDC Topics (cdc.silver.patients, cdc.silver.conditions,
cdc.silver.encounters, cdc.enrollment.changes)
↓
RAF Consumer Service (streaming)
↓ (<5 seconds)
Gold Risk Scores + Care Gap Priority Refresh
↓
Provider Portal / Worklist (real-time update)
Each clinical event — a new condition, a new encounter, an enrollment segment change — publishes a Kafka message. The RAF consumer service processes it immediately, recalculates the patient's risk score using the three-tier CMS-HCC V28 engine, and refreshes all open care gaps with updated priority scores.
What Changes Operationally
Care manager workflow. Instead of working from a yesterday's-data worklist, care managers see a live feed of risk changes. A patient who had their CFA (Community Full Benefit Dual Eligible) status corrected to CNA (Community Non-Dual) at 9am — a 20-30% coefficient change — is immediately re-prioritized in the worklist.
Coding queue. NLP-extracted suspect HCCs flow from the clinical document processing pipeline through Kafka to the coding queue within seconds of document ingestion. Coders review in near-real-time rather than next-day batches.
Gap priority accuracy. When a patient's RAF score changes, the relative priority of their open care gaps changes too. A patient who was in the MODERATE tier yesterday might be VERY_HIGH today after a new high-severity HCC is documented. The streaming pipeline recomputes gap priority scores immediately using the formula: star_weight × urgency_factor × type_weight × 10.0.
Enrollment segment handling. Dual status code changes (CFA → CNA → MCAID transitions) have direct impact on which HCC coefficient column applies. In a batch architecture, these changes sit overnight. In a streaming architecture, the enrollment segment audit records the before/after RAF delta immediately — for both operational alerting and for RADV audit documentation.
The Debounce Problem
Real-time streaming introduces a problem that batch jobs don't have: event flooding. A single patient encounter may trigger dozens of Kafka messages as individual observations, conditions, and encounters are written sequentially to the source system.
A production RAF streaming pipeline needs a two-tier debounce strategy:
Condition events (30-second debounce): ICD-10 codes are often entered and corrected within seconds of each other. A 30-second debounce prevents redundant RAF calculations for mid-typing changes.
Enrollment events (5-second debounce): Enrollment segment changes need to propagate faster — they affect payment calculations — but still need a short debounce for concurrent writes.
Without proper debouncing, a patient with 50 conditions could trigger 50 RAF recalculations within 10 seconds, overwhelming the scoring engine and creating unnecessary audit rows.
Audit and Compliance Implications
The streaming RAF pipeline creates a continuous audit trail that batch processing cannot produce. Every time a patient's risk score changes — including the old_raf, new_raf, and computed raf_delta — an immutable row is written to the risk score history table.
For RADV purposes, this creates a time-series record of every RAF change and the clinical event that caused it. If a RADV auditor asks "why did this patient's RAF score increase from 1.2 to 1.8 on March 15th?" — the answer is in the audit log, timestamped to the second, with a pointer to the bronze-layer source record.
This is not possible with nightly batch scoring. You can show the before-and-after, but not the specific event chain that caused the change.
Is Real-Time Right for Every Use Case?
Batch processing is still appropriate for:
- •RADV submission generation — requires a point-in-time snapshot, not a streaming view
- •Annual benchmark calculations — needs a stable historical dataset
- •dbt Gold layer models — complex multi-join analytics run efficiently as nightly batch
- •CMS submission files — regulatory submissions are point-in-time by definition
The right architecture uses streaming for operational workflows (care management, coding queues, worklists) and batch for regulatory and financial outputs (CMS submissions, shared savings calculations, annual quality measure rates).
AssureLogix's streaming RAF engine runs on Kafka with a two-tier debounce, nested SAVEPOINT pattern for audit safety, and real-time care gap priority refresh. The same pipeline feeds the Provider Portal with live patient risk changes. Book a demo to see the latency in action.