OPERATIONS / RESEARCH NOTE

Sent to a queue. Accepted by whom?

A request can leave the agent and still be unfinished. Follow it far enough to know which team has accepted it and what happens if it remains unresolved.

THE ACCEPTANCE QUESTION

A destination is not an owner. A closed task needs a closure reason.

Make the handoff states explicit.

FHIR R4 distinguishes a request being received from it being accepted, and both from completion. That vocabulary is useful even where the actual workflow uses another representation. A local queue status must be checked against its operational meaning. Read the status definitions.

01Sent

The sending side attempted the handoff.

02Accepted

A receiving team accepted responsibility.

03Resolved

The agreed outcome and closure reason are recorded.

For a live transfer, observe whether the patient actually reaches the receiving person. For asynchronous work, observe the task, its owner and its follow-up rules. The evidence needed is different.

Recovery work is part of the workflow.

The DirectConnect service-improvement study describes problems with messages and repeated attempts to reach patients, and an approach linking call routing with the EMR and care team. It makes the operational burden of callbacks visible. The local study does not establish results for an AI agent or another institution. Read the study.

Our proposed assessment follows the unfinished request: who detects that it needs attention, who accepts it, what evidence they receive, and what happens when contact is unsuccessful.

A terminal status does not explain the outcome.

A task might be closed because a patient was reached, because it was a duplicate, because it was redirected, or because contact attempts ended. Preserve the reason. Do not automatically count all closed tasks as successful patient outcomes.

Agree due times and the review cutoff. Work that is not yet due belongs in a different category from overdue unresolved work. If policy pauses the clock, record why and when.

Test the receiving operation.

  1. Trace one logical request to its receiving work item.
  2. Establish what counts as acceptance and which team owns it.
  3. Exercise an unavailable receiving team or failed live transfer in the agreed test environment.
  4. Observe the deadline, escalation and recovery path.
  5. Inspect closure reasons and any outstanding patient communication.
  6. Confirm that legitimate requests remain usable after changes.

The listed scenarios are proposed tests. They were not executed by our published cancellation-authority lab.

Measure unresolved work at the right cutoff.

Report accepted ownership among eligible handoffs, overdue unresolved work among items due by the cutoff, and observed hands-on recovery time. Keep attempts separate from logical requests. A burst of retries should not be mistaken for new patient demand.

Use the result to decide whether the local handoff is ready, needs a correction, or needs better evidence. Historical telephone claims illustrate serious failure mechanisms, but their selected sample cannot tell us how often your callbacks fail.

Sources & evidence limits.

Published research informs the questions. The application to your configured workflow requires its own evidence.

  1. HL7 International · FHIR R4 v4.0.1Task status vocabulary

    Distinguishes requested, received, accepted and completed states. Local mappings and actual recording must be verified.

  2. Bowman & Smith · The Permanente Journal · 2010Primary Care DirectConnect

    A local service-improvement study of call routing and EMR integration. Its results are not a forecast for other institutions.

  3. Katz et al. · Journal of General Internal Medicine · 2008Patient Safety and Telephone Medicine

    Retrospective telephone-related malpractice case review. A selected claims sample, not a denominator for everyday calls.

FROM RESEARCH TO YOUR WORKFLOW

Make the next decision with evidence.

Start with six questions. Leave with an evidence-request brief you can use with your team.