All Articles

Low Adoption of Referral Automation: A Practical Recovery Plan

Find out why staff bypass an available referral workflow, then test a correction against actual task completion and remaining work.

Linear Health Editorial Team
Linear Health Editorial Team
Editorial, Linear Health
Published
Miniature staff at a desk point from a worklist screen to a checked handoff card passing along a tray to a colleague
Diagnose why staff bypass an available referral workflow, repair the documented obstacle and check verified completion.

Start with the task staff are avoiding

"Nobody uses the platform" is too vague to investigate. Name the administrative task, the staff role expected to perform it, the point at which it becomes ready and the evidence that it finished.

For example: an intake coordinator should reconcile an incoming referral with its episode, record required administrative information and pass the next action to the receiving queue. That task ends when the receiving responsibility is accepted. Opening a record or clicking a transfer button is earlier in the process.

Choose a task that the deployed configuration is intended to support. If an entire required function was never delivered, record a scope or capability gap. Calling that "low adoption" assigns the wrong problem to staff.

AHRQ's workflow toolkit addresses both administrative and clinical work around health IT. Its tools include process mapping, interviews and usability evaluation. Use those methods to investigate the actual task rather than relying on a usage dashboard alone. See AHRQ: All Workflow Tools.

This article begins after a workflow is available. The referral automation implementation plan covers initial configuration, training and release readiness.

Define an eligible-work denominator

Write an adoption definition that another analyst could reproduce. A useful starting point is:

Workflow-use rate = eligible task opportunities started in the intended system / all eligible task opportunities in the observation cohort.

Then add a separate measure:

Verified completion rate = eligible task opportunities completed through the intended workflow with required evidence / all eligible task opportunities in that cohort.

Specify whether an opportunity is an episode, a document reconciliation or an assigned follow-up. Do not mix those units. Several tasks may belong to one episode, and one task may involve several application events.

Record when the task first became ready. Give the cohort a defined follow-up window, and report tasks still in progress at the checkpoint. Otherwise, work arriving on the last afternoon may look unsuccessful solely because it has had less time to finish.

Separate legitimate exclusions from adoption barriers. A task outside the deployed scope can be excluded with a reason. An intended user whose permissions are misconfigured should remain visible as an access problem affecting eligible work. Removing every difficult case would turn the rate into a measure of the easiest cases only.

Use the referral tracking guide for episode and task definitions. Adoption analysis should reuse that vocabulary rather than create a new set of operational states.

Examine one week without treating use as success

Hypothetical example: A team reviews 400 unique intake episodes from a fixed receipt week. Sixty are outside the deployed workflow's scope. Forty have not reached the defined administrative readiness point by the checkpoint. The remaining 300 each represent one eligible intake-task opportunity.

Of those 300 opportunities, staff start 180 in the intended system. They complete 135 with the required handoff evidence, while 45 remain started but unresolved at the checkpoint. The other 120 use another process without starting the intended workflow.

Observed outcomeTask opportunitiesShare of eligible work
Started and completed with required evidence13545%
Started, completion not yet established4515%
Intended workflow not started12040%
Total eligible opportunities300100%

The workflow-use rate is 180 / 300, or 60%. Verified completion through that workflow is 135 / 300, or 45%. These are task measures, not a claim that 45% of referrals resulted in completed care.

The 45 unresolved tasks require a second look. Some may be progressing normally; some may have stalled. Preserve their actual state and elapsed observation time rather than classifying them all as software failures.

The 120 bypassed opportunities are the starting point for the adoption investigation. The 100 excluded episodes remain in the report with their reasons, so leadership can see the gap between deployed scope and total incoming work.

Ask what the workaround makes possible

Review a permitted sample with the people doing the work. Ask them to show the last point where the system supported the task and the first point where they switched to something else.

Useful prompts include: "What were you trying to establish here?" "What did the other list tell you?" "How did you know the next team accepted it?" and "What happens if you follow the documented steps exactly?"

Record observations separately from explanations. "Coordinator copied the episode ID into a shared list" is an observation. "They distrust automation" is an interpretation. The list might provide an acknowledgment missing from the application, or it might duplicate information unnecessarily. Test which explanation fits.

Use this original investigation worksheet:

FieldWhat to captureWhat it helps decide
Intended taskStarting condition and required resultWhether the work belongs in this workflow
Break pointLast usable step and next attempted actionWhere to reproduce the problem
WorkaroundActual alternate actionWhich need the current process is serving
Stated reasonStaff explanation in ordinary languageWhat hypothesis to test
Observable evidenceMissing field, permission, acknowledgment or other resultWhether the explanation is supported
Repair ownerOperational, system, vendor or training ownerWho can change the condition
Acceptance testTask and expected evidence after correctionHow to tell whether the repair worked

Do not turn the worksheet into an employee ranking. Its purpose is to find defects in the task and the working arrangement. Broader workload and staff-support questions belong in the referral coordinator burnout guide.

Choose the repair that matches the evidence

Continue the hypothetical example. Investigation assigns one primary bypass reason to each of the 120 opportunities: 55 lack visible receiving-team acknowledgment, 30 involve incorrect permissions for an intended role, 20 require duplicate entry into a retained process, and 15 reveal an unclear task instruction. These counts total 120 and are invented for this exercise.

Keep secondary contributing reasons in separate fields. If one task has both a permission problem and a training problem, counting it twice in the primary-reason table would exaggerate bypass volume.

Each reason points to a different repair. The acknowledgment issue needs a confirmed handoff signal. The permission issue needs an authorized access correction. Duplicate entry needs a decision about which record is authoritative and whether the retained step remains necessary. An unclear instruction needs a clearer procedure and task practice.

A training session cannot establish a missing acknowledgment. A new screen cannot settle disputed ownership. The repair owner should be the person who can change the observed condition, even when that person sits outside the referral team.

For external referring offices that still use fax, consult the fax-to-electronic transition guide. Sender channel adoption is a different project from internal staff use of an available worklist.

Run a task test before announcing the fix

NIST's EHR usability guidance distinguishes observing people perform realistic tasks from collecting opinions about a demonstration. It also describes diagnostic usability testing of deployed systems. That distinction is useful when investigating a referral workflow staff already have. See NISTIR 7741.

Create a synthetic version of the failed task. Ask a representative staff member to work through it using the permissions, instructions and receiving arrangement intended for that role. Explain the task goal without coaching each click.

For the acknowledgment issue, the test could read: "Pass this reconciled episode to scheduling, then show how you know who accepted the next action." The expected evidence is an accepted destination task linked to the episode. A sent notification alone does not pass.

Record the outcome, any assistance required, the step that caused uncertainty and the evidence the participant used. If the participant succeeds only after the observer explains a hidden signal, the task still needs work.

Include a covering colleague, an unavailable receiving owner and a returned task in the test set where those situations belong to the deployed scope. A repair that works only for the person who designed it is insufficient evidence for broader use.

Use the test to verify the specific repair. It is not a certification that all workflows are usable or an estimate of how every employee will perform.

Check whether useful adoption changed

Write the follow-up method before releasing the correction. Preserve task eligibility, cohort timing and completion evidence. Record changes in staffing, case mix, scope or receiving-team coverage that may affect interpretation.

Hypothetical follow-up: A later comparable cohort contains 300 eligible opportunities. Staff start 210 in the intended workflow; 195 finish with the required evidence and 15 remain unresolved at the checkpoint. Ninety bypass it. The outcomes reconcile: 195 + 15 + 90 = 300.

Use rises from 60% to 70%, a 10 percentage-point change. Verified completion through the workflow rises from 45% to 65%, a 20 percentage-point change. Neither figure alone proves the correction caused the improvement. They identify a pattern to investigate with the task results, workload observations and any concurrent changes.

Look behind the new total. Did the acknowledgment problem become less common? Are staff maintaining fewer duplicate lists? Did another team inherit additional work? Count repeat attempts and correction work separately so a higher completion rate does not hide more effort per task.

Adoption is also not financial realization. Use the separate postlaunch referral automation ROI review when assessing measured benefits and costs. Do not convert a usage percentage directly into staffing savings.

Leave a durable instruction, not another temporary workaround

Once a correction works under the agreed test, update the task instruction where staff look for it. State the trigger, action, completion evidence and exception owner. Remove conflicting guidance through the organization's normal change process.

For a retained workaround, record why it is still needed and who owns the unresolved dependency. Do not quietly make a second list permanent because the initial project has ended. Equally, do not withdraw a functioning fallback before its replacement can support the required task.

Give staff a short route to report recurrence, including the affected step and observable result. Review whether the same defect returns with new staff, changed assignments or new source documents. That evidence determines whether the repair needs adjustment or whether a different problem has appeared.

For referral coordination automation, begin with the work staff need to complete, then bring one bypass example, its denominator and the result your team needs to verify to a workflow review.

FAQ

What is a good referral automation adoption rate?

There is no universal target supported by this method. Define the eligible work and intended outcome, then examine your own trend and unresolved reasons. A high start rate can coexist with poor task completion. Publish both measures and keep excluded work visible.

Should we retrain everyone when adoption is low?

First determine whether the obstacle is knowledge, functionality, permissions, ownership or another workflow condition. Training fits a demonstrated instruction or task-practice gap. Use a focused test to confirm that staff can finish the task after the relevant correction.

Do logins prove that staff adopted the workflow?

No. A login proves an access event under the system's definition. It does not establish that an eligible task began or finished. Link adoption measurement to task opportunities and their completion evidence, while using login information only as supporting context.

Should permission problems be excluded from adoption reporting?

If the role and task belong in the deployed scope, keep the barrier visible. Report access-affected opportunities separately rather than removing them to improve the rate. Work outside the intended scope can be excluded, with its count and reason disclosed.

How do we know when to stop the recovery effort?

Close the specific issue when its repair passes the agreed task test, affected work is accounted for and the follow-up evidence supports the result. Keep normal feedback and monitoring in place. One resolved bypass reason does not prove every part of the system has been adopted.

Sources

Linear Health Editorial Team
Linear Health Editorial Team
Editorial, Linear Health
Share this article
Keep reading

Related articles

Stay updated

Get the latest on AI healthcare coordination.