Post-discharge follow-up automation: a TOC controls checklist

Start with the care-transition workflow

Transitions of care cover more than a notification. The operational workflow may need to receive a discharge or referral signal, identify the right person, assemble authorized context, assign follow-up work, track communication, and route unresolved needs to the responsible team. The organization should define which transition types and settings are in scope before comparing software.

CMS Transitional Care Management guidance describes a specific Medicare service with defined settings, components, timing, and practitioner responsibilities. An enterprise workflow may support parts of that work, but a software queue is not proof that a service requirement was met, that a patient is eligible, or that a claim is supportable.

Build post-discharge queues from authorized signals

An enterprise can automate post-discharge follow-up queues by receiving approved discharge, referral, scheduling, and task-status data, matching the record to the correct patient, applying organization-defined routing rules, and assigning the result to an accountable staff role. Every queue item should show why it exists, which source supplied the signal, when the source was updated, and what information is missing.

A useful design distinguishes a candidate task from a verified obligation. Duplicate messages, late feeds, missing contact preferences, conflicting discharge dates, and unmatched records should move to explicit exception states instead of silently creating or closing work.

• Name the event that starts each type of follow-up workflow.
• Show source system, source timestamp, matching status, and routing reason.
• Assign every task and exception to a role with an aging rule.
• Require human review before any action the organization classifies as sensitive or clinical.

Treat EHR-agnostic as an architecture requirement

A TOC agent can be designed to work with discharge data from different EHRs, but it still needs an approved path to each required field. That path might be an API, governed feed, transition-of-care document, warehouse, health information exchange, scheduling system, or enterprise integration layer. The product should not imply a production connection that has not been implemented and validated.

For each source, document the field meaning, allowed use, refresh expectation, provenance, patient-matching method, duplicate handling, failure behavior, and whether the workflow is read-only or writes a status back. ONC's transitions-of-care material and current SAFER Guides provide useful context for information exchange, patient identification, communication, system management, and contingency planning.

Require communication and access controls

The organization should define which roles can view, assign, export, contact, suppress, or close a record and which data those roles need. For an evaluation, ask for an approved role-to-field access map and test it with representative authorized records. The organization must determine the applicable privacy and legal requirements; this checklist does not establish legal compliance.

Communication workflows also need approved channels, identity checks, language and accessibility handling, contact preferences, consent rules where applicable, escalation paths, and a record of what was attempted. The enterprise, not a marketing page, must determine how its legal, privacy, security, clinical, and operational requirements apply.

• Which role approves contact and which role handles a clinical question?
• How does the queue distinguish no response, wrong contact, declined contact, and unresolved need?
• Which events are auditable, and how are corrections preserved?
• What happens when a feed, interface, directory, or downstream system is unavailable?

Use a seven-part TOC evaluation checklist

Score testable evidence rather than broad claims. The evaluation should show how the workflow behaves with representative records, errors, delays, duplicates, and exceptions before any production use.

• 1. Intended use: transition types, users, sources, outputs, and prohibited actions.
• 2. Program mapping: current operational and, where relevant, CMS requirements separated from vendor features.
• 3. Data contract: authorized fields, provenance, freshness, patient matching, duplicates, and failure states.
• 4. Human control: owners, approval points, escalation, reassignment, and queue-aging rules.
• 5. Communication: approved channels, contact preferences, accessibility, language support, and status definitions.
• 6. Validation: representative cases, false inclusion and exclusion review, downtime tests, rollback, and monitoring.
• 7. Evidence package: architecture, security materials, test results, limitations, support model, and claim references.

A fictional read-only pilot

Consider a fictional health system testing a read-only workflow for one approved discharge source. The workflow creates a staff review task only when identity matching and required routing fields pass the organization's test rules. Each item shows the source timestamp, transition type, reason for inclusion, owner, and next approved action.

A conflicting discharge date, missing contact preference, duplicate transition, or uncertain patient match moves to an exception queue. Staff decide whether and how to follow up. The pilot does not send autonomous clinical advice, create a claim, determine coverage, or write back to an EHR.

Measure observable workflow behavior

Useful pilot measures include source events received, records matched, duplicates detected, tasks created, exceptions by reason, queue age, reassignment, staff dispositions, approved contact attempts, and unresolved handoffs. Define the denominator, source, time window, owner, and acceptable threshold for each measure before the pilot begins.

These counts can describe operational behavior. They do not by themselves establish clinical benefit, avoided readmissions, compliance, billing accuracy, reimbursement, return on investment, or any other outcome that requires separate evidence.

Start with the handoff, not the closed label

The SAFER Test Results Reporting and Follow-Up guide addresses test-order status, identifiable follow-up responsibility, notification of amended results, and monitoring of acknowledgment and follow-up. [1] The official ONC resource page links to the guide. [2]

The template below is Synodha's proposed evaluation aid, not a required software layout from ONC. It is designed to expose one question: what evidence would let a reviewer distinguish an administrative handoff from completed follow-up? Clinical leaders must define the answer for their setting.

Give each event its own evidence field

Keep operational task ownership separate from clinical responsibility. A coordinator can chase missing acknowledgment while the responsible clinician retains review and treatment decisions. Use only authorized fields and approved access; a general task board is not a place to copy a full result or patient chart.

• Source item: the authorized record reference and its timestamp. Record whether the result is still pending or available without interpreting its clinical meaning.
• Routing: the intended recipient, transmission time and delivery or failure evidence. A sent flag belongs here, not in the clinical-review field.
• Acknowledgment: the receiving person's or team's recorded acceptance. If the source has no acknowledgment, show unknown rather than inferring it from delivery.
• Clinical review: a reference to the accountable clinician's documented review in the approved system. Software should not invent a review note or infer review from opening a message.
• Disposition: the documented next action, communication or other completion evidence required by the organization's rule. A clinician may determine that no further action is needed; the queue must not make that judgment.

Test a delivery-without-review example

In a synthetic evaluation, task T-001 has a delivery receipt but no receiving-team acknowledgment and no linked clinician review. The safe display is delivered, acknowledgment unknown, review unverified. It is not follow-up complete. The example contains no real patient, result value, diagnosis or treatment instruction.

Then add an acknowledgment without a review record. The status should change only for that checkpoint. Finally, provide the organization's required review and disposition evidence. Test whether the closure rule checks those exact fields instead of counting messages sent. Also test a corrected result: the organization must decide when prior closure requires reassessment, rather than silently leaving the earlier label unchanged.

Handle missing evidence without guessing

Before a pilot, ask the organization to define the exception owner, coverage arrangements, review deadlines and escalation path. Do not choose a universal waiting period or allow an operational queue to override an urgent-result protocol. Preserve unavailable, failed and unverified as distinct states so a missing interface event does not become a false success.

For a small audit, compare closed tasks with the required evidence references. Count tasks reopened for missing evidence and tasks with unresolved ownership separately. These are proposed process checks, not clinical outcomes, reimbursement measures or claims that the product has improved care.

Where Setu fits, and what this guide does not claim

Setu is Synodha's transitions-of-care workflow agent for preparing authorized discharge-related work queues and exceptions for accountable human review. [3] This template is a buyer evaluation aid, not a claim that a particular connector, acknowledgment feed or closure rule is already configured in a customer's environment. Define available data, permissions and human approvals with the organization before any implementation.

This is not patient-specific medical, billing, legal or compliance advice. It does not diagnose, interpret test results, choose treatment, guarantee reimbursement or promise fewer readmissions. Synodha does not claim endorsement by AHRQ, ASTP/ONC or an EHR vendor. For an evaluation, describe the workflow without sending patient information through a public inquiry form.

Limitations to keep visible

• Care-transition programs, CMS requirements, and organization policies can change and need named owners for review.
• Discharge, referral, identity, and contact data may be late, incomplete, duplicated, or inconsistent.
• EHR-agnostic design still requires approved interfaces, mapping, validation, access controls, and operational ownership for every enterprise.
• A checklist cannot establish legal or regulatory compliance. Each organization needs its own review.
• Workflow support does not replace the responsible practitioner, care team, patient-specific judgment, coverage verification, documentation, coding, or claims processes.
• Setu is live in production across three enterprise deployments. Synodha does not claim EHR endorsement, compliance status, billing accuracy, reimbursement eligibility, autonomous clinical decision-making, reduced readmissions, or another clinical outcome.

How this guide was prepared

Synodha's editorial team prepared this guide from the official sources listed below and checked product statements against the current documented enterprise scope. No independent clinical, legal, compliance, customer, or EHR-vendor review is claimed. This guide is an evaluation aid, not clinical, legal, compliance, billing, or reimbursement advice.

Last reviewed October 3, 2026. Recheck the linked sources and the healthcare organization's current instructions before acting on health information.

Primary sources and scope

These sources establish the current program and health IT context used for this checklist. They do not endorse Synodha or establish that any product or deployment is compliant.

• CMS: Transitional Care Management Services booklet
• ONC: Transitions of care certification companion guide
• ONC: 2025 SAFER Guides for patient identification, clinician communication, system management, and contingency planning
• [1] SAFER guide PDF: practices 2.1, 2.2, 2.3 and 3.1
• [2] ONC: SAFER Test Results Reporting and Follow-Up resource page
• [3] Synodha: Setu TOC Agent, documented intended workflow and limits

Related Synodha resources

• Start here: fee-for-service to value-based care transition guide
• Explore Setu TOC Agent
• Compare Synodha's enterprise healthcare agents
• Review the US healthcare portfolio
• Evaluate AWV outreach automation
• Evaluate CCM workflow automation
• How Synodha works with health systems