Callback and Referral Operations Workbook

A working agreement for the people who send, receive, recover, and review patient-access requests. Use one copy per receiving process. Complete it together with the sending team, receiving team, and operational reviewer. Bring the actual queue labels, routing configuration, staffing calendar, and a small authorized sample of request histories.

This workbook proposes local operating definitions and measurement rules. It is not a mandated status model, a clinical triage protocol, or a validated scoring instrument. Clinical urgency and contact policies belong to the organization’s approved procedures. All worked records below are fictional.

How to use the pack

1. Define the outcome you are tracking: a callback, a scheduled appointment, or the entire referral loop. Record separate milestones when the scope spans several teams.
2. Map the existing statuses. Keep useful local labels; make their meanings and evidence explicit.
3. Agree when responsibility transfers, including automatic assignment where that is how the operation works.
4. Specify closure reasons and the owner of anything still outstanding.
5. Apply a fixed review cutoff, reconcile logical requests against attempts, and assign corrections.

The editable Markdown and CSV templates can be completed in an organization-approved local workspace. The printable version has space for decisions. The CSV pack contains templates and a fictional arithmetic example; it does not calculate operational results automatically. Use reference IDs rather than copying patient details into review materials.

1. Process scope

A callback to arrange an appointment can be complete while a referral remains open. Record the callback as a child task and retain the referral’s ID. A patient can have several distinct requests; a patient ID alone is not a request ID. Conversely, repeated calls about the same unfinished need should remain linked to the original request.

2. State dictionary

Use this proposed vocabulary to explain local states, not to prescribe a sequence of screens. A record may legitimately pass straight into owned work. Some systems keep technical delivery, work status, ownership, and closure reason in different fields; retain that separation.

FHIR distinguishes received, accepted, and completed work. Its ready status also supports workflows where assignment and acceptance are already established. The R4 and R5 definitions both include that option. These are versioned technical definitions, not proof that a local queue is staffed or functioning. (HL7 R4, HL7 R5)

The operational label “received” above is a local proposal. FHIR received specifically includes a potential performer claiming the task to evaluate it; do not map an interface delivery receipt to that code without checking the semantics. Escalation and reopening may be events or flags rather than exclusive states.

Local mapping sheet

Complete one row for each label in use, including ambiguous labels such as “done,” “processed,” “forwarded,” and “complete.” Add rows as needed.

Mapping review: Which label could lead a reviewer to overstate completion? ____________. Who will correct the definition, display, or export, and by when? ____________.

3. Receiving-process agreement

IHI/NPSF recommends shared referral agreements, explicit responsibilities, tracking, backup plans, and minimizing administrative burden. Its 2017 guidance concerns ambulatory referrals and informs the questions here; this workbook’s fields and rules are proposed adaptations for local operations. (Closing the Loop, pp. 15–19)

Acceptance route A: explicit acknowledgment

Document the action that records agreement to perform the work, the accepting person or team, and its timestamp. Name the person or process responsible for pending work before that event. Decide how a rejection is communicated and recovered. A read receipt or message-open event counts only if the agreed workflow actually gives it the meaning of acceptance.

Local acknowledgment event / evidence: ____________. Interim owner: ____________. No response by due time: ____________.

Acceptance route B: defined automatic assignment

Document the rule that makes the receiving team responsible when an eligible work item is created or assigned. Record its version, eligible request types, effective hours, destination, assignment timestamp, and exception path. Check that the team can see the item and that coverage and backlog monitoring match the agreement. Evidence can be the configured rule plus its observed assignment record; an additional confirmation click is unnecessary when it adds no operational decision.

A routing label by itself is insufficient evidence. If the destination is disabled, the item cannot be created, or the request falls outside the rule’s eligibility, record the exception and the recovery owner. If assignment remains valid outside staffed hours, record immediate ownership separately from the later staffed-time action deadline.

Rule / version: ____________. Assignment event and owner field: ____________. Eligibility / exception route: ____________. Observed evidence reference: ____________.

Conditional combination

For example, routine scheduling callbacks may be assigned automatically while incomplete referrals require receiving-team review. Document the dividing condition, the owner while review is pending, and the evidence for each route. Report the two routes separately when comparing acceptance performance. Do not add sequential acknowledgments simply to make every request follow the same diagram.

Capacity and due-time example

Fictional operation: two coordinators each have 90 minutes available for callbacks in an interval. At an assumed six minutes of direct work per request, that is a theoretical capacity of 30 requests before recovery, meetings, or variation. Reserving 36 minutes for recovery leaves 144 minutes, or 24 requests under the same assumption. With 28 incoming requests and four already waiting, there are 32 requests against that assumed capacity of 24: an eight-request gap requiring an operating decision. This is planning arithmetic, not a staffing benchmark; replace every assumption with local observations.

For a separate fictional due-time example, a team works Monday–Friday, 09:00–17:00 local time, with no holiday on the following Monday. A request arriving Friday at 16:30 with two staffed hours allowed is due Monday at 10:30. A two-elapsed-hour rule would instead make it due Friday at 18:30. Record the actual date, named time zone and applicable calendar. “Within two hours” alone does not settle the promise.

4. Closure taxonomy

Choose a primary reason for each work-item closure and preserve secondary detail. Record who closed it, when, what evidence supports the disposition, what was communicated, and whether the original need remains open. These are proposed local categories, not FHIR codes or billing definitions.

Closure decision record

Two common traps: A referral scheduling item may close as redirected while the successor is still waiting for acceptance. A callback item may close as unsuccessful contact while the referring team still needs to decide what happens next. Neither event is a resolved logical request.

CMS50v14 for the 2026 performance period measures receipt of a specialist report and uses a patient-based denominator. The request-based operating measures below are different. Do not label them CMS50 performance or infer that a closed queue item meets that measure. (CMS50v14 specification)

5. Measurement worksheet

Fix the population before calculating

Use one row per logical request in the request sheet and one row per attempt in the attempts sheet. Keep one row per receiving work item in the work-items sheet to preserve redirects and multiple queues. Repeat contacts, retries and successor tasks retain the same logical request ID unless there is a genuinely new need under the agreed definition. Store delivery attempts separately from patient-contact attempts.

Count statuses as of C, not as of the date the extract was downloaded. Exclude events after C from that snapshot. Preserve closure and reopening events so an earlier snapshot can be reconstructed. An open request includes waiting, paused, escalated, redirected work with an unresolved successor, and reopened work.

Population reconciliation

Assign each logical request to exactly one snapshot bucket:

• Resolved: the documented outcome was met by C and was not reopened by C.
• Closed without resolution: an authorized final disposition ended tracking of that need without the outcome being achieved. Keep the closure-reason mix visible.
• Open: further action remains; subdivide by the next unresolved milestone’s effective due time.
• Unknown outcome: evidence cannot establish one of the above. Missing closure evidence must not become a success.

For open work, overdue means effective due time is at or before C; not yet due means it is after C; missing due time is a separate data-quality bucket. This workbook uses an inclusive deadline boundary. If the organization chooses a different convention, record and apply it consistently. A pause does not remove work from the population. Preserve raw age since creation and the next pause-review date as well as any approved adjusted deadline.

Measures and denominators

Use separate acceptance, next-action and outcome deadlines where they represent different obligations. Do not make an unresolved referral look timely by repeatedly moving a callback deadline. Retain original and effective deadlines, change reasons, approvals, and the deadline history used at C. When an outcome is unknown, show that uncertainty rather than claiming a confirmed failure or success.

Fictional worked snapshot

Cutoff: 15 September 2026, 17:00 UTC. The cohort contains six distinct logical requests and seven receiving work items; one duplicate work item belongs to R1. For simplicity only in this example, next-action and outcome due times are identical for each open request. All six handoffs have evidenced ownership by the cutoff. There are no missing due times or unknown outcomes.

Reconciliation: 6 = 2 resolved + 1 closed without resolution + 3 open + 0 unknown. Open work splits into 2 overdue + 1 not yet due + 0 missing due time. The duplicate item adds neither a seventh logical request nor a resolved outcome.

Four requests have outcome deadlines at or before C: R1, R2, R4 and R6. Three are not resolved, so the due-cohort unresolved share is 3 / 4 = 75%; its components are two open and one closed without resolution. Open overdue workload is 2, not three. Early resolution of R5 does not put it into the due cohort yet.

The 12 contact attempts belong to 6 requests, giving 2 attempts per contacted request. There are 30 observed recovery minutes, all six requests have time observations, and four have positive recovery time. Mean recovery time across requests with positive recovery is 30 / 4 = 7.5 minutes; the mean across all six observed requests is 5 minutes. Name the denominator. None of these numbers describes a real service.

Blank readout

6. Operational review and recovery

Repeated unsuccessful return calls created extra staff work in the historical DirectConnect service-improvement study. That local experience motivates observing recovery effort; it does not establish savings for an AI service or another institution. (Bowman and Smith, 2010)

Review a small, authorized set of traces spanning normal assignment, after-hours arrival, capacity breach, missing information, redirect, unsuccessful contact, duplicate and reopening. These are proposed review scenarios, not executed findings. For each trace, identify the responsible process before acceptance, after acceptance, at escalation, and after closure. Follow one item beyond the first queue when another team must act.

A historical malpractice-claims review identified documentation and triage problems in selected telephone-related cases. Its selection cannot estimate everyday callback failure rates. Use it as context for careful records, not as a prevalence benchmark. (Katz et al., 2008)

Review decision: ready for the defined scope / correction required / evidence insufficient: ____________. Reason and evidence: ____________. Correction, owner, deadline and recheck: ____________. Sending and receiving leads’ agreement: ____________.

Sources and limits

1. HL7 International. Task status vocabulary, FHIR R4 v4.0.1. 2019. Definitions of received, accepted, ready and terminal states; R4 is a version-specific reference.
2. HL7 International. Task status vocabulary, FHIR R5 v5.0.0. 2023. Confirms the assignment-and-acceptance option in ready. Neither vocabulary requires extra interface clicks.
3. Institute for Healthcare Improvement / National Patient Safety Foundation. Closing the Loop: A Guide to Safer Ambulatory Referrals in the EHR Era. 2017, pp. 15–19 and 25–33. Expert guidance on agreements, responsibility, tracking and communication; not an evaluation of this workbook or an AI product.
4. Centers for Medicare & Medicaid Services. Closing the Referral Loop: Receipt of Specialist Report, CMS50v14, version 14.0.000. 2026 measurement period. Cited to distinguish a specified patient-based quality measure from local request-based operations. Later-period versions must not be substituted for the applicable reporting period.
5. Brent Bowman and Scott Smith. Primary Care DirectConnect: How the Marriage of Call Center Technology and the EMR Brought Dramatic Results—A Service Quality Improvement Study. The Permanente Journal, 2010;14(2):18–24. Historical local improvement study; no AI effectiveness claim or projected savings used here.
6. Harvey P. Katz, Dawn Kaltsounis, Liz Halloran and Maureen Mondor. Patient Safety and Telephone Medicine: Some Lessons from Closed Claim Case Review. Journal of General Internal Medicine, 2008;23(5):517–522. Selected retrospective malpractice claims; not a service-wide failure denominator.

Sources checked 15 September 2026. The operating fields, six-reason taxonomy, calculation conventions, and fictional examples are Access Red Team proposals. Local definitions, clinical policies, operating hours, thresholds and performance need organization-specific evidence. No universal response time, required number of contact attempts, prevalence estimate, or compliance certification is asserted.