Referral Automation Scope: Turn a Proposal Into Acceptance Evidence

Why a proposal is not a scope document

A proposal phrase such as "automates referral intake" leaves several questions open. Which inputs are covered? What record changes? Who handles an unreadable document or a missing administrative identifier? Use the acceptance plan to resolve those questions before treating the phrase as a completed delivery requirement.

The AHRQ Workflow Assessment for Health IT Toolkit frames the underlying problem: health IT changes both clinical and administrative workflow, and the planning, design, implementation and use stages each need their own workflow attention (AHRQ). A scope document is where you make the administrative workflow explicit before the technology is live.

This article sits between two neighbours. If you are still collecting quotes, start with the referral management RFP template. If scope is already accepted and you are planning rollout, see referral workflow automation implementation. The work here is the conversion in between: one selected proposal into observable delivery acceptance.

Translate each proposal promise into observable work

Take every sentence in the proposal that describes what the system will do and run it through four questions:

1. What arrives? The document, message, record or event that starts the step.
2. What leaves? The record, status, task or notification produced, and where it is written.
3. What stops it? The conditions under which the step cannot complete automatically.
4. Who sees the result? The person or queue that inspects the output.

The Linear evaluation kit asks for a similar breakdown: identify every step the system completes, every step a person completes, and every handoff between them, and define completion in observable terms including the final status and where it is recorded (Linear Health). A proposal sentence that cannot answer all four questions is a requirement to resolve, not a promise to accept.

Worked translation (synthetic)

Proposal line: "Incoming referrals are captured, classified and routed to the right scheduling queue."

This is illustrative. Field names, routing rules and which EHR actions are possible depend on the vendor's demonstrated integration with your system. Verify the actual field actions and event coverage in the proposed configuration. A logo or a broad integration label does not supply that evidence. Apply the same questions to any vendor.

Name the inputs, outputs and staff-owned exceptions

Once each promise is translated, build three lists.

Inputs register. For each input, note the source system, the format, the expected volume range and who on your side is responsible for it being available. If the vendor needs a fax line forwarded or an EHR interface enabled, that is buyer work with an owner and a date.

Outputs register. For each output, note the destination, the field or status that changes, and how a user would confirm it happened. Describe the promised output precisely. If it is a task, name its queue, required fields and owner. If it is a referral record update, name the record and event that verifies it. One output is not inherently better; the evidence must match the agreed requirement.

Exception register. List every condition that routes work to a person. For each, name the queue, the role that owns it, and the expected response window if one is agreed. The evaluation kit lists the inability to show who owns an exception or how an incorrect action is corrected as a red flag (Linear Health). Use the register to identify the work retained by staff. Do not infer that share from a general automation percentage.

Add an exclusions list alongside the three registers. Anything the proposal mentions that will not be in the first delivery, such as a second location, a payer portal, or a referral type, goes here with a note on whether it is deferred or out of scope entirely.

Write acceptance evidence that both parties can inspect

A statement of intent is incomplete as an acceptance criterion until it identifies inspectable evidence. Use the four-level evidence scale from the evaluation kit as the shared standard: not addressed, claimed, demonstrated in a controlled scenario, and verified in production (Linear Health). Then decide, for each scope line, which level is required at which milestone.

The kit separates acceptance criteria for launch, stabilization and ongoing operations. A practical pattern, offered as editorial guidance:

• Launch acceptance: the required actions and relevant failure paths demonstrated against agreed criteria. Use representative cases, then add the variations needed for the actual scope. One example does not establish coverage of every condition.
• Stabilization acceptance: permitted production evidence reviewed against an agreed observation window, scope and sampling plan, with actual exceptions and correction history. If a rare case has not occurred, retain its test evidence and mark production evidence unavailable rather than claiming it was observed.
• Ongoing acceptance: a recurring review of the exception queue, correction history and any change requests.

For each criterion, write the artifact you will look at: a timestamped workflow trace, a written in-scope and out-of-scope list, an exception queue export, a completion record in the system of record. These examples adapt the evidence requests in the kit's workflow dimension. If you cannot name the artifact, the criterion is not yet inspectable.

Keep privacy, security and authorization items separate from scope scoring. The kit treats them as gates that a high total cannot offset, and routes them to the responsible reviewer. The workbook records the responsible reviewer and evidence dependency. It does not make the underlying security, legal or clinical decision.

If you want a scope conversation anchored to your own referral flow, you can book a demo and bring the workbook with you.

Work a synthetic scenario from intake through disposition

The following is a labelled synthetic example. It is not a Linear customer experience and contains no measured results.

Setting: A multi-site specialty group receiving referrals by fax and EHR order. The selected proposal promises intake, classification, routing, patient outreach for scheduling, and status write-back.

Case A, ordinary intake. A synthetic fax contains the administrative fields required by this fictional configuration. Expected output: a referral record in the agreed queue, with the specified source reference and fields. Acceptance artifact: the source, receipt event, record creation event and resulting record, checked against the written expected values.

Case B, unresolved identity. The synthetic input lacks an identifier required by the fictional approved matching policy. Expected behavior: preserve the incoming item in the exception queue without an unverified patient-record write. Acceptance artifact: the preserved item, reason, assigned owner and authorized resolution. This example does not prescribe a universal patient-matching policy.

Case C, unsupported specialty. Referral for a service the group does not offer. Expected behaviour: routed to the "out of scope referral" queue, not to scheduling. Acceptance artifact: queue entry plus confirmation nothing was written to the scheduling queue.

Case D, outreach with no response. Patient does not answer the scheduling contact after the agreed attempts. Expected behaviour: status updated to the agreed "unreached" value and a task assigned to a named role. Acceptance artifact: the contact-attempt events, status history and assigned task in the system of record.

Disposition. For each case, the workbook records the final status, the system holding it, and the person who inspected it. The four cases illustrate how to write expected results. They are not a complete launch acceptance set: the owners must add the integration failures, duplicate handling and other variations required by the actual proposed scope.

Notice what the example does not do. It does not estimate time saved, completion rates or cost. Those belong in a separate value model with baselines and denominators, which the evaluation kit addresses under its outcomes and cost dimensions. Mixing them into acceptance evidence makes both harder to check.

Record accepted scope, open requirements and change decisions

Close the workbook with a decision log in three parts.

Accepted scope. Each scope line, its evidence level at launch and stabilization, the artifact inspected, the inspector and the date.

Open requirements. Record claimed, untested and failed items with owners, the needed evidence and the decision they block. A target date makes a dependency trackable; it does not establish acceptance.

Change decisions. Every addition, deferral or removal after signature, with who requested it, who approved it and the effect on acceptance criteria.

Commercial terms sit alongside this log, not inside it. Linear's public pricing: From $2,000 a month. Flat monthly fee per workflow, sized to your volume. You pay nothing monthly until the workflow is live and processing real work. Its public go-live wording: First workflow live in 4 weeks. Whatever vendor you choose, record the trigger that starts billing and the milestone it depends on next to the acceptance criteria that define that milestone.

Practical evaluation method

1. Extract every capability sentence from the proposal into a list.
2. Translate each into input, output, stops and observer.
3. Build the inputs, outputs and exception registers and the exclusions list.
4. Assign a required evidence level and artifact per scope line for launch and stabilization.
5. Run the synthetic case set agreed for the actual scope, including normal actions and relevant failure paths.
6. Log accepted scope, open requirements and change decisions.
7. Route privacy, security and authorization items to their reviewers as gates.

For referral coordination specifically, see how Linear Health handles referral coordination, then book a demo and we will walk a synthetic case set against your referral sources.

Frequently asked questions

Sources

Sources accessed October 25, 2026.

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