Stop treating “sent” as a completed referral handoff.

A PROPOSED RESPONSE

What to change or check.

1. In the approved system, distinguish sending, confirmed receipt and a confirmed next action. Use the statuses the local pathway actually supports.
2. Assign a responsible role and next-review date. Define what happens to pending, returned, declined and information-requested items.
3. At the locally agreed review point, route an unresolved item to a named escalation owner. Record the response before changing the status.

A SAFE EXAMPLE

Make the next action visible.

Illustrative example, not a client record or reported implementation result.

State

Sent; receipt not confirmed

Responsible role

Referral coordinator

Next action

Check receipt through the agreed receiving-service route

Review point

The clinic’s approved follow-up date

Evidence

Recorded response and next action, beyond the sending timestamp

TRY THE CHECK

Can the team work through it?

Run a fictional unacknowledged referral and a fictional request for missing information. Can a colleague identify the next owner, action and review point?

These demonstration checks stay in this page and are not submitted or saved. They are prompts for local validation, not a readiness score.

Stop treating “sent” as a completed referral handoff.

CLINOPILOT WORKFLOW CHECK
A sending status can be visible while the receiving team, next action or follow-up owner is still unclear.

Proposed steps
1. In the approved system, distinguish sending, confirmed receipt and a confirmed next action. Use the statuses the local pathway actually supports.
2. Assign a responsible role and next-review date. Define what happens to pending, returned, declined and information-requested items.
3. At the locally agreed review point, route an unresolved item to a named escalation owner. Record the response before changing the status.

Checklist
[ ] A responsible role is visible.
[ ] The receiving-service response is recorded rather than assumed.
[ ] The next action and review point are clear.
[ ] Unresolved and declined items have an agreed route.

Illustrative example, not a client record
State: Sent; receipt not confirmed
Responsible role: Referral coordinator
Next action: Check receipt through the agreed receiving-service route
Review point: The clinic’s approved follow-up date
Evidence: Recorded response and next action, beyond the sending timestamp

Test
Run a fictional unacknowledged referral and a fictional request for missing information. Can a colleague identify the next owner, action and review point?

Candidate local measure
For an agreed sample, record whether an owner, next action and review point are visible. Keep pending and declined items separate from confirmed handoffs.

Scope
This is a proposed operational check. Local clinical urgency, acceptance criteria and escalation rules remain with the responsible teams.

Independent published evidence
Ontario eReferral–eConsult implementation guide (Implementation guidance)
Ontario Health describes information flows across referral and consultation pathways.
Implementation context does not validate this checklist or a particular clinic’s outcomes.
https://ehealthontario.on.ca/en/standards/ontario-ereferral-implementation-guide-fhir-overview
CorCare Link public implementation reference (Published implementation reference)
CorCare Link supports community referral and ordering workflows.
Capability availability does not establish successful handoff completion.
https://nlhealthservices.ca/corcare/for-health-providers/community-physicians/corcare-link/

https://clinopilot.com/proof/referral-handoffs/
Use approved tools and fictional or process-level examples. Do not add patient information to public requests.

How to review the result locally.

For an agreed sample, record whether an owner, next action and review point are visible. Keep pending and declined items separate from confirmed handoffs.

This is a proposed operational check. Local clinical urgency, acceptance criteria and escalation rules remain with the responsible teams.