Referral Workflow Changes: Decide What Clinics Can Change Locally

Why change authority is a separate problem from standardization

A network needs a way to maintain workflow decisions after an initial standardization project. A request to adjust routing, add a status, move overflow or revise a message can affect people who did not request it. Make those dependencies visible before deciding who can approve the change. This article concerns that ongoing decision, rather than the initial acquisition integration or vendor selection.

The AHRQ Workflow Assessment for Health IT Toolkit frames the core issue: health IT affects both clinical and administrative workflow, and once implemented it can provide information to help reorganize and improve workflow. The governance question is who is allowed to act on that information, and at what level.

This article is distinct from our guides on standardizing referrals across PE-backed clinics and evaluating multi-site referral automation. Those cover the initial rollout and the vendor decision. This one covers what happens on an ordinary Tuesday when a practice manager wants to change something.

Separate local configuration from shared workflow definitions

Start by sorting every configurable element into two buckets.

Local configuration is a candidate for delegated authority only after its effects have been checked. Queue membership can alter access; working hours can affect patient-facing channels; worklist order may intersect with an approved priority rule. A setting is not low impact merely because one site can edit it. Record the checks and delegation that permit a local owner to act.

Shared workflow definitions are anything that other sites, central reporting, or patients depend on. Examples: routing rules that send a referral from one site to another, the list of referral statuses and what each one means, how workload is counted for staffing or performance review, and the wording of outbound patient and provider messages.

A useful dependency check is whether the change alters what another team sees, receives, counts or communicates. If the answer is unclear, record the unknown and resolve ownership before applying it.

Assign decision rights for routing, statuses, workload and messages

The proposed matrix below uses three rights. Local means the site changes it and records it. Local with notice means the site changes it but must notify a named central contact before go-live. Central means a central owner approves before the change is made. The assignments are a starting proposal; adjust them to your structure.

Two notes. First, anything that touches eligibility, coverage, consent or clinical triage is outside this matrix and belongs with the relevant accountable reviewer. Second, if a vendor platform automates part of routing or messaging, the same rights apply: a configuration change in the tool is still a workflow change. The Linear Health evaluation kit makes the related point that automated actions should be logged and correctable by an authorized user, which is the capability a decision owner needs to enforce the matrix.

Create a change request with a reason and affected work

The proposed request should be short enough to use and specific enough to review.

1. Before and after. Name the exact field, rule, route or message and retain the current version.
2. Observed reason. Describe the problem, observation period and affected work without inventing a causal explanation.
3. Dependencies. Identify sites, roles, permissions, reports, integrations and communication channels that use the changed value.
4. Acceptance evidence. Define normal, missing-data, conflicting-update and recovery cases appropriate to the scope.
5. Release and recovery. Name the approver, person applying the change, rollout boundary, stop condition and recovery owner.

A synthetic status-change request

An invented three-site group proposes an Awaiting Documents status because its current Pending label does not identify the next administrative action. The operations owner first defines entry and exit evidence. The reporting owner checks how the existing dashboard groups statuses; integration owners check consumers of the field. The request proposes a limited initial rollout, with an explicit mapping for sites that retain the older label.

Test synthetic episodes that enter the new state, receive a late document, receive a conflicting update and move to the next authorized step. Confirm both the worklist and the report. The network can choose a common label or documented local mappings; comparability depends on the agreed meaning and evidence, not simply on every site displaying identical words.

The recovery plan retains prior status events and disables further use of the new value if needed. It specifies how open items are reconciled into an approved state. Deleting the status or rewriting historical events is not an acceptable substitute for that decision. This scenario is editorial guidance, not a customer result.

Test the proposed change and retain a recovery path

Borrow the evidence standard from the evaluation kit rather than inventing a new one. It asks for one representative case with normal complexity, missing data and at least one exception, and distinguishes a claimed change from one demonstrated in a controlled scenario from one verified in production (Operational AI Evaluation Kit). For a local workflow change, that translates to:

• Start with synthetic records in an approved test environment. Include the dependencies and failure cases required by the change.
• Include one case where the needed information is missing or late.
• Confirm where the final status is recorded and that reports pick it up.
• Test recovery before go-live. Identify which configuration can be reverted and which completed actions require separately authorized correction.

Keep a recovery record for every released change: version, release time, affected scope, person who applied it, stop trigger, recovery owner, prior configuration and reconciliation steps for work already processed. A configuration rollback cannot unsend a message or erase a task another team has acted on. Preserve history, identify affected items and confirm corrective actions under the approved process. Move from testing to a bounded production rollout only after the responsible owners accept the evidence.

If you are considering automation for routing or messaging, ask the vendor to show how a user pauses, corrects or reverses an automated action and who owns an unresolved exception. These are listed as evidence checks in the kit. You can book a demo and ask Linear Health to demonstrate which correction and recovery actions the proposed configuration supports. Put the same questions to other vendors.

Review whether the local change should become shared practice

Set a review date when the change is approved, typically after enough volume has passed to judge it. The review has three outcomes.

• Promote. The change solved a problem other sites share. Convert it to a shared definition, update the matrix if needed, and roll it out with the same change request discipline.
• Keep local. The change works but depends on something specific to that site. Record why so it is not mistaken for drift later.
• Recover or revise. The evidence did not support the intended result or revealed a dependency. Follow the recovery record and reconcile affected work before another release.

The review is also where you catch definition creep. If sites have added near-duplicate statuses, compare their entry evidence and consumers before deciding whether to map, rename or retire a value. Preserve historical meaning when changing the current vocabulary.

A practical evaluation method you can run this quarter

This is editorial guidance, not a measured method.

1. Export every configurable element in your referral workflow and sort each one as local or shared.
2. Draft the decision-rights matrix with named owners. Circulate it to site managers for objections before adopting it.
3. Review a manageable set of recent changes. Record its scope and limits, classify each against the proposed matrix and inspect missed dependencies.
4. Pick one pending request and run it through the full change request, test and recovery record.
5. Set a review trigger that allows the agreed evidence to accumulate, with earlier action when a stop condition is met.

If part of your referral coordination is automated, read our referral coordination software overview for how workflow configuration fits alongside staff work, and book a demo if you want to walk through your matrix against a live workflow.

Frequently asked questions

Sources

Sources accessed November 5, 2026.

• AHRQ, Workflow Assessment for Health IT Toolkit.
• Linear Health, Operational AI Evaluation Kit.
• Linear Health, Referral Coordination Software.