Health Agents Need Source Recency Bands

The Danger of Flat Medical Context

A user uploads an Apple Health export and an EHR discharge summary into ChatGPT and asks one question: is my chest pain today anything to worry about, given my history? The pipeline retrieves the most semantically similar chunks and builds its answer around them. One of those chunks is a well-written oncology consult note from 2018. Another is a three-line vitals log from an Apple Watch, captured ten minutes ago, showing a resting heart rate spike.

In a naive RAG setup — no recency metadata, no filtering, no reranking — the 2018 note can outrank the ten-minute-old vitals fragment. It’s longer, better structured, and full of the clinical vocabulary that embeds close to the query. A three-line fragment doesn’t have that semantic density, and it scores worse on cosine similarity as a result.

In the developer prototypes we reviewed, the pattern was consistent: Apple Health exports and EHR summaries pushed into a single vector index, with no source-specific freshness model and no field for how old is this, and does it matter. A lab result from three years ago and a glucose reading from three minutes ago sit in the same index, ranked by the same retrieval math. That’s not a prompt engineering gap. It’s a data model failure — and it produces a specific, dangerous failure mode: the agent answers confidently, using a baseline that stopped being true a long time ago.

Telemetry Decay: Lessons from Water-Tech and Clinics

We’ve run into this exact problem before, in two systems that have nothing to do with chatbots. Both are first-hand builds — no external sourcing to cite, just what we shipped and what broke.

The first was a queue management system we built for outpatient clinics. Nurses at the triage station took vitals — blood pressure, temperature, pulse ox — and logged them before the patient sat down to wait for a doctor. The wait could run long, and by the time the doctor called the patient in, the vitals on screen were sometimes an hour or more old. Nobody had built a mechanism to flag that. The doctor would glance at a triage reading and treat it as current, because the interface drew no distinction between “just taken” and “taken before the patient’s queue number was even called.” We eventually bolted on a staleness indicator tied to a timestamp delta, because the failure mode wasn’t hypothetical — it was a doctor working off a blood pressure reading that predated the actual consult by 45 minutes.

The second was WaterDoctor, our deep-tech investee in industrial water filtration. Sensor telemetry across a reverse osmosis (RO) plant doesn’t age uniformly. Membrane pressure readings can turn stale within seconds — a spike now can mean fouling is happening right now, and the signal loses value fast. Supply tank levels, by contrast, stay valid for hours; nobody expects a tank to drain meaningfully in the time it takes to check a dashboard. We built the monitoring stack around that asymmetry from the start. Averaging or flattening those signals into one “system health” score would have masked exactly the failures that mattered.

Human physiology behaves the same way, just on different clocks. A continuous glucose monitor stream is meaningful for minutes. A medication list holds until the next prescription change — typically weeks. A genomic screen is valid for a patient’s lifetime, more or less. Treat all of that as one flat embedding space, retrievable by semantic closeness alone, and you repeat the same mistake we corrected in a filtration plant and in a clinic waiting room. The lesson transfers directly: multi-speed data needs multi-speed retrieval logic, not a single similarity score.

Implementing Exponential Time Decay in Vector Search

Cosine similarity has no concept of time. It measures how closely two vectors point in the same direction — and a well-written old note points in a very convincing direction. The fix is to penalize the raw similarity score with a decay function tied to data type and elapsed time, applied at retrieval, not at generation.

The standard shape for this is exponential decay applied to the base score:

$$\text{score}_{\text{final}} = \text{score}_{\text{cosine}} \times e^{-\lambda \cdot \Delta t}$$

Where $\Delta t$ is the elapsed time since the data point was recorded, and $\lambda$ is a decay constant assigned per source type. A chunk tagged type: wearable_vitals gets an aggressive $\lambda$ — one that drives the multiplier toward zero within minutes to a few hours. A chunk tagged type: surgical_history gets a $\lambda$ close to zero, so the multiplier stays near 1 for years. Medication lists and lab panels sit in between, decaying over days to weeks rather than minutes or years.

This isn’t a research proposal. It’s implementable with tools already sitting in production stacks. In pgvector, a SQL expression can compute the exponential term from a recorded_at column and multiply it against the cosine-derived similarity before ranking, so the decay happens inside the query rather than as a post-processing step bolted onto application code. In Milvus, the more portable path is to use scalar fields like recorded_at and source type for pre-filtering or to pull a candidate set first, then apply the decay-weighted score in a reranking step — unless the specific Milvus version and search path in use supports the score expression natively. Either way, the requirement doesn’t change: the decay math has to run during retrieval. Run it after generation, or not at all, and the LLM has already been handed the wrong baseline. No amount of downstream prompting fixes that.

The Expiration of the Standard Medical Disclaimer

A footer that reads “not intended for medical diagnosis” is not an architectural control. Under ISO 14971-style medical-device risk management, the control belongs in the pipeline: freshness checks, documented thresholds, and an escalation path when context is stale. A UI disclaimer may still exist, but it is not a substitute for a documented risk-control measure. A pipeline that retrieves a three-year-old baseline to answer a chest pain query, with no freshness weighting anywhere in the retrieval path, has no risk control to point to beyond that footer.

The fix has to live in the pipeline itself, as a hardcoded escalation branch. If the agent detects a symptom query — chest pain, shortness of breath, sudden vision change, the usual triage red flags — and the only chunks it can retrieve above a minimum relevance threshold fall below the freshness weight for that data type, the agent shouldn’t generate a clinical-sounding answer. It should drop the response and route to a human clinician, or issue an explicit “seek care now” instruction. Think of it the way you’d think of a circuit breaker in a distributed system: when the inputs are known to be unreliable, you don’t degrade gracefully into a wrong answer. You halt.

The Baseline Requirement for Health AI

Medical context is governed by time as much as by content. A pipeline that scores relevance purely on meaning, and ignores when the data was true, will be confidently wrong on a predictable schedule. We’ve seen it in clinic vitals sitting stale on a triage screen, and in filtration sensors that would have masked a fouling membrane if their signals had been averaged together. Health agents built on flat RAG risk hitting the same wall — with worse stakes attached.

The audits coming for health AI won’t stop at “is the retrieved fact accurate.” They’ll ask how the system scored that fact’s expiration, and whether an escalation path existed for the moment the data ran out. Architectures that can answer both questions with a number, not a disclaimer, are the ones built to last.