A message is the beginning of a task
A result arrives, a patient sends a question, or a clinician requests a follow-up appointment. Each event creates work, but the work can become difficult to track when it moves through separate inboxes. A message marked as read may still need a decision. A request forwarded to another team may still be waiting for someone to accept it.
An illustrative clinic workflow starts by turning the event into a task with a purpose, an owner, and an observable next step. The task stays connected to the original patient context so the next person does not need to reconstruct the reason it exists. This is a workflow design pattern, rather than a substitute for the clinic's clinical protocols.
Separate receipt, review, and completion
One status label cannot explain an entire handoff. A team needs to distinguish whether information has arrived, whether an authorized person has reviewed it, and whether the required follow-up has been completed. Those states answer different questions and should not collapse into a single green badge.
For example, a scheduling request can be received, assigned to the front desk, awaiting patient contact, and then booked. A result-related task may need a separate clinical review before any patient communication. Use names that describe the work actually completed, and avoid assuming that opening a record closes the task.
- Received: the task and its source are available.
- Assigned: a person or team has accepted responsibility.
- In progress: the next action is underway or a dependency is pending.
- Completed: the defined outcome and its evidence are recorded.
Make the handoff an explicit event
Shared ownership does not mean that everyone is equally responsible at every moment. Show a primary owner, the team supporting that owner, and any transfer of responsibility. When a task moves between teams, keep the reason for the transfer and the previous work attached to it.
Coverage matters too. The clinic should define how tasks move when an owner is absent, a shift ends, or a queue is not staffed. A routing rule can propose the destination, but the receiving team needs a dependable way to acknowledge the handoff and identify cases it cannot take on.
Keep waiting work visible
Many follow-ups depend on someone outside the immediate team. A patient may need to return a call, a record may need to arrive, or another service may need to respond. Treating every waiting task as active work can overwhelm the queue; hiding it entirely can make the dependency disappear.
A useful waiting state records what the team is waiting for, who will check again, and the next review point defined by the clinic. The queue can surface that task again when the dependency arrives or the review point is reached. An unavailable system should be identified as a technical problem, rather than an indication that no action is needed.
Use evidence to define a closed loop
ONC's SAFER guidance includes the safe use of EHR processes for communicating and managing test results. It provides a useful starting point for clinics evaluating their own result workflows. Applying that principle to task design means making the expected outcome explicit and keeping the supporting record connected to the task.
Completion evidence might be a documented review, an appointment confirmation, or a recorded communication outcome, depending on the task. A failed contact attempt should remain distinct from a successful conversation. Clinical leaders should define what completion means for each workflow and how unresolved work is escalated.
Measure the handoffs that need attention
A queue's total size is only part of the story. Review unassigned work, repeated transfers, reopened tasks, and cases that remain dependent on missing information. Look at the reasons behind delays before drawing conclusions from a single turnaround-time metric.
Start with one follow-up workflow and walk it through with the people who handle it. Map the event, the decisions, the handoff, and the final outcome. A connected operating layer becomes useful when every team can see what happened, what remains open, and who owns the next step.
The loop closes when the intended work is completed and its outcome is visible.
