The missing execution record between discharge, scheduling, communication and follow-up

Start with an open operational question

When a patient goes home, how does the team confirm the first follow-up happened, and how does it get picked up when it hasn’t? The question leaves room for an existing reliable process. TCM research adds receiving-side context, but a provider affiliation or billing record does not identify the receiving practice for a hospital’s particular discharges. That connection needs confirmation in conversation and, where useful, authorized local records.

A discharge instruction, an appointment, an outreach attempt and a completed follow-up may each exist in a different system. The operational gap is often not the absence of those records. It is the absence of one governed record that explains whether the transition obligation moved from one state to the next.

A collection of completed tasks is not automatically proof that the end-to-end job completed.

From events to an accountable job

Consider a bounded obligation: arrange and confirm an appropriate follow-up after discharge. Its state may depend on clinical instructions, scheduling capacity, patient communication, an external provider and a human exception decision.

1. Discharge obligation
2. Scheduling attempt
3. Confirmation decisionConfirmed: create handoff receipt. Not confirmed: route to human exception queue and return for another scheduling attempt.
4. Handoff receipt

The useful record is more than a timestamp. It needs the obligation identifier, current owner, source evidence, applicable policy, expected completion window, decision, handoff acceptance, exception state and closing receipt.

Why interfaces alone do not close the gap

An interface can transfer a message successfully while the operating obligation remains unresolved. A scheduling API may accept a request but return no appropriate capacity. A message may be delivered without confirming comprehension or completion. An external referral can be transmitted without acceptance.

This is why Lime Health separates action receipts from job closure. The action system reports what it did. The execution record evaluates whether that result satisfies the agreed obligation and policy. Ambiguous or unsafe cases stop at a human-controlled exception path.

An accountable care-transition team can see which scheduling, outreach or external-provider step still needs attention when an unresolved patient-facing obligation is visible. That visibility does not establish why the obligation is open. It also does not establish whether an intervention is clinically appropriate or whether closing the obligation will change a readmission outcome.

A hospital-authorized risk-stratification result could become one governed input into eligibility or prioritization. Lime Health would preserve the model and version, applicable population, source data, threshold and human authority. It would then record whether the resulting intervention was offered, accepted, completed, changed or left unresolved. A risk score would not determine clinical action by itself. Intervention completion would not prove causation.

A shared record without replacing existing systems

The intended shared record would show the next owner, whether the receiving party accepted the handoff, what remains open and what confirms completion. It would refer back to the clinical, scheduling and communication systems responsible for their own records.

That is a design goal for later scoped work. The current public-data portal does not track a hospital’s live referrals, appointments or patient follow-up. First ask whether existing tools already connect those events reliably. A second queue that creates more reconciliation would be a poor result.

Where to begin

A hospital does not need to model every transition at once. Begin with one high-friction obligation and ask:

• Which source event opens it?
• Which fields are minimum necessary?
• Who can recommend, approve, act and close?
• What conditions route it to an exception?
• What receipt is sufficient?
• Which measures show completion, delay, rework and unintended burden?

A useful discovery output is not an automation backlog. It is a versioned map of the obligation, evidence, owners, handoffs, exception routes and confirmation of completion.

See our approach →

Related: Six HRRP measures, six transition lenses

Follow the unresolved referral through its states

Continuing the synthetic scenario in Article 2. Transmission is an Event supported by the sending system’s receipt. Arranging an accepted follow-up is an Obligation. Lack of acceptance at a locally agreed checkpoint can produce a Signal for review; it does not prove that the practice refused the referral.

Attendance and subsequent clinical outcomes remain separate events or obligations. No fabricated deadline is a clinical recommendation. If a record arrives late, retain both when the reported event occurred and when the team learned about it. This distinction explains a decision made with incomplete evidence without rewriting its history.

A practical discovery artifact is one row per state transition with the responsible role and required receipt. It exposes uncertainty before an integration project begins.

Payment-lens continuity

Payment context can explain why an unresolved transition deserves attention. It belongs with the signal and research decision, while confirmation of completion remains grounded in obligations, accountable roles, events, exceptions, action receipts and observed outcomes.

Sources and boundary

See CMS QualityNet readmission methodology for the program measure boundary. The workflow described here is an Lime Health operating model, not a CMS-defined causal explanation or patient-specific recommendation.