Close the loop the discharge order opened
A discharge order creates time-critical dependencies at outside facilities. “Referral sent” is not “patient on the schedule” — and nobody trips the alarm on the first miss. This spine verifies every dependency to CONFIRMED, and screams on day two instead of at next week’s huddle.
The open loop
A discharge order creates a hard dependency at an external facility — a weekly OPAT infusion, an outpatient dialysis chair, a PCP follow-up, home health, durable equipment. Someone “sends the referral” and the order is marked done. But referral sent is an unverified claim. The receiving facility confirms the patient is on its schedule is a verified one.
Nobody runs that verification, and no tripwire fires when the first session is missed. Two weeks of silence should have screamed on day two. This isn’t exotic — it’s the textbook transition-of-care handoff failure, and closing it isn’t a templating problem. It’s clinical judgment encoded as software: knowing that “weekly OPAT to a SNF” is a hard dependency that must be confirmed before discharge counts as done.
The verification spine
Every downstream dependency carries exactly one status. Only CONFIRMED closes the loop — the gate will not flip to confirmed on “referral sent” alone. As a required session approaches, an escalation ladder ramps from a quiet nudge to urgent to overdue, and a lapsed session goes critical.
The receiving facility confirms the patient is on its schedule, and no required session has lapsed. The loop is closed.
The order exists but nothing is booked — no referral on record and no confirmation. The slot still needs to be secured.
A referral was sent but the slot is not yet confirmed. The loop is open and unverified as the session approaches — the exact “referral sent” trap.
A required session passed with no confirmation or recorded attendance. The handoff loop is open and overdue — escalate immediately.
It happened twice in one day
Both de-identified by construction — no names, MRN, DOB, or dates, and none ever will. Each is the same bug: a discharge created a time-critical dependency at an external facility, and nobody closed the loop.
A patient discharged to a SNF on a weekly outpatient IV-antibiotic course missed her infusions: no one placed her on the infusion-center schedule. The referral was “sent” — she was never actually booked. Status should have stalled at UNVERIFIED and tripped MISSED on the first lapse.
An ESRD patient never secured an outpatient dialysis chair after discharge and bounced back uremic and fluid-overloaded, now on inpatient acute HD. At discharge the dependency was UNSCHEDULED; the never-attended session should have screamed long before the readmission.
Interactive demo
Pick a dependency type and a scenario. Every verdict below was computed by the actual verification engine — the same pure logic that runs in production — over PHI-free synthetic cases at a fixed clock. No PHI, no network call, no guesswork: just the engine’s status, rationale, and next action.
What it is — and isn’t
It displays, organizes, and flags the verification state of each discharge dependency for clinician review — a clinical-decision-support tool on the flag-don’t-diagnose side of the line.
The engine runs only on a de-identified contract — dependency type, facility class, due-by, status. Never a name, MRN, DOB, or a named facility. PHI stays inside the customer’s own environment.
It makes no clinical determination. It does not diagnose, recommend treatment, or decide care. The product flags; the clinician decides.
Status is derived purely from booking flags and timestamps versus the clock — no black box. Every verdict carries a plain-language rationale and a next action you can audit.
The fastest path is a walkthrough on synthetic cases, then a scoped pilot inside your own environment — the engine deploys as software you run, so PHI never leaves your covered entity. Start with an intro call.
Want a deposit-backed pilot slot? Reserve a pilot — deposit
Pilot deposit checkout is being finalized — for now, request a demo by email and we’ll send the deposit link with your engagement letter.