Stanford Med · Unit 5B Medicine·Day shift·Mon · 9:42 AM

Dynamic plan engine

How the discharge plan updates daily as patient data changes
The dynamic discharge thesis

The discharge plan must update every time the patient does.

BNP drops · PT eval comes back · payer approves · caregiver answers the portal · vendor confirms the slot — every signal can change the plan. OpenBed listens to all of them, recomputes the six readiness dimensions, diffs against the last snapshot, and routes the change to the right human or external system within seconds. The plan is never static.

Push, pull, scheduled sourcesDurable via InngestIdempotent (prompt-hash cache)Every change audited
Event sources · everything that can re-trigger a discharge plan

10 typed sources · push, pull, or scheduled

SourceKindProtocolCadenceExample payload
Epic FHIR Subscription
via Epic Systems
pushFHIR R4 Subscription (REST hook)Real-time pushObservation BNP=420 (down from 1820) · MedicationRequest Entresto created
HL7 v2 ADT listener
via Hospital integration engine (Mirth-style)
pushHL7 v2.x (A01/A02/A03/A08)Real-time pushA08 — patient updated (new attending assignment)
Payer auth webhook
via CoverMyMeds, Availity
pushCoverMyMeds + Availity webhookOn decisionEntresto PA APPROVED · BlueShield MA · TAT 6h 14m
Vendor callback (SNF / DME / NEMT)
via Naviguide, Lincare, ModivCare, Twilio+Vapi
pushPartner REST / voice-agent transcriptOn vendor responseBayview SNF · ACCEPTED · bed Tue 10AM · pre-auth confirmed
Patient portal event
pushInternal SSEReal-time pushCarla submitted SNF preference: Bayview 1st, Hillcrest 2nd
Task completion (internal)
pushInternal event busReal-time pushPT mobility assessment complete · op readiness +14 pts
Voalte / Vocera ack stream
via Vocera/Voalte/Halo
pushVocera/Voalte webhookReal-time pushAisha Patel acknowledged PT page · ETA 13:15
Eligibility pull (X12 270 → 271)
via Availity
pullX12 270/271 via AvailityOn admit + on plan changeBlueShield MA active · SNF benefit: 100 days · PA required
4pm pharmacy cliff detector
scheduledInngest cronDaily 15:30, 15:45, 15:50, 15:553 patients with pending Rx + retail closes 16:00 · escalate to pharmacy
Friday morning weekend forecaster
scheduledInngest cronFri 07:005 patients exposed to weekend gap · pre-stage weekend prep tasks
Recompute pipeline

Every event flows through these 7 stages — durable via Inngest workflows

  1. 1
    Event ingestion

    Webhooks, FHIR subscriptions, HL7 listeners, cron ticks land on the bus.

  2. 2
    Normalization

    Raw payloads converted to typed internal events; deduplicated by hash.

  3. 3
    Per-patient re-evaluation

    Six-pillar readiness recomputed · brain detectors re-run · resource matches re-ranked · disposition re-scored.

  4. 4
    State diff

    Compare new snapshot to previous; emit one diff entry per material change.

  5. 5
    Routing engine

    Each diff → mapped to a target (UI surface · external API · audit row · notification).

  6. 6
    Outbound action + UI push

    EHR writeback · CoverMyMeds submit · portal SSE · Voalte ping · toast on operator screen.

  7. 7
    Audit + idempotency

    AgentInference + Submission rows written; prompt-hash cache prevents loop.

Worked example · Michael Johnson Day 0 → Day 4

10 events · each traced source → recompute → diff → routed → audit

Day 01 events
  1. Recompute
    • Spawn Encounter + AgentInference link
    • Pull baseline FHIR bundle (chart, meds, allergies)
    • Trigger chart-summarizer agent via runAgent
    State diff
    • Encounter created · LOS clock starts
    • Predicted disposition: SNF (0.76 conf)
    • Predicted EDD: Tue 14:00
    • 3 baseline barriers seeded (PT eval pending, SNF prefs not captured, transport not scheduled)
    Routed to
    • CM Console census · UI refresh
    • Maria Chen (assigned CM) · Email digest
    Audit row
    Written to spine
    AgentInference#chart_summarizer · cost $0.014 · latency 2.1s
Day 11 events
Day 22 events
Day 35 events
Day 41 events
How this screen works
This page documents the engine that runs on every screen
Inputs
What this screen reads
  • EVENT_SOURCES catalog (src/lib/architecture/dynamic.ts)
  • MICHAEL_TIMELINE worked example data
  • PIPELINE_STAGES configuration
Engine
What it computes
  • Renders event source table with kind/protocol/cadence
  • Renders 7-stage pipeline diagram
  • Renders expandable per-event timeline with recompute → diff → routed → audit
Outputs
What it writes / routes
  • Cross-link to /cm/architecture (component map)
  • Cross-link to /cm/integrations (partner status)
  • Cross-link to Michael Johnson cockpit (live patient view)
Refresh trigger
When it updates
  • Edits to dynamic.ts when adding new event sources
  • Updates to Inngest workflow definitions
  • New partner integrations (added to EVENT_SOURCES)
Partners involved:Inngest (workflow engine)Anthropic (LLM runtime via runAgent)Epic / Cerner FHIR SubscriptionsCoverMyMeds / Availity webhooksNaviguide / Lincare / ModivCare callbacks
Engineering note

Why durable workflows?

Hospital integrations fail. A FHIR endpoint times out, a fax delivery bounces, a webhook arrives out of order. Inngest's durable execution retries with backoff and dedup — we don't lose events.

Engineering note

Why idempotency matters

The same eligibility response arriving twice cannot create two PA submissions. Every event has a hash; the engine skips duplicates within the cache window. The runAgent wrapper has the same property for LLM calls.

Engineering note

Why a worked timeline?

Investors and design partners need to see one patient go through the full loop. Michael Johnson is our canonical example — 10 events across 4 days, every diff audited, every surface refreshed.

Demo data · no PHI · mocked Epic + payer endpoints