Referral Automation Implementation: A Phased Plan With Release Gates

Implement referral automation in phases: confirm the selected scope, map the current process, establish a baseline, configure and test the workflow, train responsible staff, and release a monitored pilot. Expand only when the required evidence is complete. Each phase needs an owner, a deliverable, acceptance criteria, and a recovery process for work that cannot continue automatically.

Start where procurement ends

Implementation begins with the agreed purchase. Identify which workflows, locations, interfaces and service responsibilities are included, and which remain conditional.

Create a delivery register with one line per operational capability. Attach the relevant proposal or scope reference, buyer owner, vendor owner, dependency and acceptance evidence.

Resolve discrepancies between what staff expect and what the agreement includes. "Referral automation" may mean intake and assignment in one scope, but outreach and documentation follow-up in another.

This guide concerns delivery after selection. Use evaluating multi-site referral automation for pre-purchase evidence or healthcare workflow automation when deciding which project to start.

The release gates below are an original proposed operations plan. They are not a universal implementation timetable or proof that a product is ready for a particular organization.

Phase 1: Map current work and define the release boundary

Follow one example of each in-scope administrative path. Record the trigger, systems, current owner, wait, output and exception route.

Ask staff where they keep work that the official process does not accommodate. A personal checklist or shared spreadsheet may reveal a required function that the delivery plan missed.

Define exactly where the release begins and ends. For an intake pilot, it could begin with confirmed receipt and end with accepted assignment to scheduling. The pilot should not claim a completed referral journey merely because that shorter process works.

List excluded tasks and the owners who continue performing them. Staff should not have to infer whether a task remains manual.

The phase output is a map, a boundary statement and a record of open questions. Do not configure ambiguous responsibilities into software and expect the launch to resolve them.

Phase 2: Establish a usable baseline

Choose measures that correspond to the release boundary. For intake, these might include receipt accounting, elapsed time to assignment, unresolved exception age and active handling minutes.

Record the source, definition, cohort and observation period. State when data is unavailable or sampled. A baseline with clear limits is more useful than a precise-looking estimate with no method.

Keep leading administrative measures separate from later outcomes. A short pilot may reveal interface defects before enough time has passed to assess visit completion.

The referral operations dashboard guide provides a fuller metric dictionary. For this project, choose only the measures needed to evaluate the in-scope behavior.

Freeze the baseline method before release. If the method changes, recalculate comparable periods where possible or label the break explicitly.

Phase 3: Configure the workflow and its exceptions

Supply approved field definitions, status mappings, document requirements, queue owners and communication rules. The implementation team should not invent clinical or coverage rules while translating operational requirements.

Define each exception with a trigger, responsible queue, next action and restart condition. "Unable to process" is too broad if the real problem could be an unreadable field, missing information or an unavailable interface.

Keep configuration versions and approval history. HL7's Provenance resource records information about how a resource version was created or changed; the release log proposed here is an original administrative tool.

Ask how staff corrections enter the history. A corrected destination or field should be traceable to the responsible action and source evidence.

Use release gates with concrete outputs

Passing a gate means its evidence has been reviewed, not merely that a meeting occurred. Keep links to the results in the delivery register.

Phase 4: Test the work, the failure and the recovery

Test connections first. Can a synthetic source record be read, and can an intended update be confirmed in the correct destination?

Then test complete administrative paths. Include a normal packet, supplemental information, a repeated transmission, an unresolved association, a missing field and a staff reassignment.

For interface failures, test both no write and uncertain write outcomes. If a request is sent but confirmation is lost, the recovery process should inspect the destination before issuing a potentially duplicating action.

Write expected results in advance. For an uncertain association, a correct result may be a held episode with a named review task. Do not classify every human handoff as a failed automation test.

For workflows involving returned documents, include the distinct consult note return process. Receipt and routing should not manufacture evidence of clinical review.

Work through a hypothetical acceptance run

Hypothetical test exercise: A team defines 30 synthetic cases: 18 normal cases, four repeated-transmission cases, three missing-information cases, three interface interruption cases, and two reassignment cases.

The cases total 30. At first execution, 27 produce the expected result and three fail. The failures are one incorrect duplicate association, one lost exception assignment and one unconfirmed write that is replayed without reconciliation.

The pass rate is 27 divided by 30, or 90%. That percentage does not establish release readiness. All three failures affect required behavior and remain blocking under the team's prewritten criteria.

After correction, the team reruns the three failed cases and the cases that exercise the changed components. It preserves the original failures and the retest evidence.

A later report should say which cases passed in the final configuration. It should not erase the initial defects or claim that 30 synthetic examples prove all real-world conditions are covered.

The release decision also checks staff coverage and recovery readiness. Software tests alone do not establish that tomorrow's exceptions will be worked.

Phase 5: Train roles using actual responsibilities

Train coordinators to identify the current owner, inspect source evidence, resolve an approved exception, and determine whether a destination update succeeded.

Train supervisors to reassign work, inspect aging, identify unowned items and pause the affected process. Train technical support on connection monitoring and reconciliation.

Use role-based scenarios rather than only a feature tour. A new coordinator should be able to show how they would handle an incomplete packet and what they must not decide independently.

Record who has completed the required exercises and which roles lack backup coverage. A named owner who is absent during launch is not operational coverage.

For role design, use the referral coordinator job description. Keep employment decisions truthful and separate from software claims. Automation does not establish that a specific staffing reduction is possible.

Phase 6: Release a monitored pilot with one production actor

Choose a scope small enough to observe and representative enough to teach you something relevant. State why its sites, document types or channels were selected.

During shadow observation, compare expected actions without allowing two processes to create competing production updates or patient contacts. One workflow must remain accountable for each action.

At pilot release, reconcile the opening worklist. Know which records are already in progress and which workflow owns them after the change.

Monitor accounted-for receipts, accepted assignments, missing owners, unresolved exceptions and unconfirmed writes. Review the actual records behind issues rather than relying only on a high-level success percentage.

Keep the pause mechanism and responsible contacts visible. Staff should know how to stop the affected process and where paused work will go.

Define recovery more carefully than a rollback

A rollback can restore configuration while leaving work already performed in the destination system. Pausing outreach does not unsend a message, and reverting a mapping does not automatically correct previously written records.

Define recovery as an operational sequence: pause the affected action, identify the impacted records, inspect which actions occurred, assign reconciliation, and resume only under the approved decision.

Preserve evidence before correction. Record the affected configuration version and time window, the responsible investigator and the final disposition of each impacted item.

Use a documented decision to restart. The restart should confirm that the defect is addressed, impacted work is accounted for, and the receiving teams are ready.

This is why recovery tests belong before launch. The team should practice finding pending and partially completed work without relying on one implementation specialist's memory.

Phase 7: Expand with a difference check

Before adding a site or workflow, compare it with the pilot. Identify changed system instances, document sources, staffing, approved local rules and reporting mappings.

Reuse evidence where it applies. Rerun affected tests where it does not. A successful first site should shorten discovery through reusable material, not eliminate necessary validation.

Carry unresolved pilot limitations into the expansion decision. Do not let a new launch date make them disappear.

Keep the delivery register open until every contracted capability and retained responsibility is accounted for. The first live referral is a milestone; it is not necessarily completion of the full program.

For referral coordination software, ask for a release plan that makes these distinctions explicit.

FAQ

Sources

• HL7 FHIR R4, Provenance resource, information about the creation and revision of resource versions, hl7.org/fhir/R4/provenance.html