How to Evaluate Referral Automation Across Multiple Sites

Build a variation inventory before a shortlist

A network of identical sites poses a different evaluation problem from a group assembled through acquisitions. Site count alone cannot describe that difference.

Start with one row per location. Record the EHR and instance, referral direction, receipt channels, staffing coverage, approved local exceptions, languages supported by the existing workflow, and reporting gaps. Ask a coordinator and a manager to review each row.

Do not assume shared branding means shared operations. Two offices can use the same EHR brand while maintaining separate configurations and local record identifiers. Conversely, separate systems may support a workable shared process if responsibilities and interfaces are clear.

The following is an original evaluation worksheet. Its purpose is to select tests, not to assign a clinical risk score.

If basic capability requirements are still unsettled, begin with the referral software buyer's guide. This evaluation adds the network-specific tests that follow.

Test configuration inheritance with a real change

Ask the vendor to establish a network default, create a permitted exception for one site, and display both in an administrative view. Then change the default.

Observe what happens to the exception. Is it preserved, overwritten, flagged for review, or disconnected from the default permanently? Any of these behaviors needs to be understood before you rely on it.

A useful test uses an administrative condition, such as which queue receives an incomplete packet. Avoid inventing clinical routing rules for a demonstration. Supply your approved policy and require the configuration to follow it.

Ask who can approve an override and where its reason appears. The proposed system should let you identify which locations depart from the standard and why. If that takes a separate configuration spreadsheet, record the maintenance effort rather than assuming it disqualifies the product.

Some vendors publish product specifications that outline what a basic package includes. Luma's public specifications page is one example. Luma Health product specifications Ask every candidate to state, for your network, what sits inside the quoted package and what does not.

Your worksheet should use separate labels for available configuration, custom development, third-party dependency, and unknown. A “supported” feature with an unresolved dependency is still unresolved for your network.

Run the same referral through dissimilar locations

Choose locations for the differences they expose. An easy pilot can demonstrate one successful configuration. It does not establish that the rest of the network shares the same fit.

Hypothetical evaluation example: A network has 12 sites: seven on instance A, three on instance B, and two on instance C. The proposed first demonstration covers one site on A and another site on A. That exercises two locations but only one of the three instance configurations.

A revised test set includes one site from each instance, plus the location with the most distinctive overflow arrangement. It does not have to process live referrals everywhere. It should expose each material configuration before the team extrapolates.

Create a synthetic referral received at one site and assigned to central intake. Add supporting paperwork from another channel. Move responsibility to a local scheduler. Inspect the full history at each step.

Record what each user sees, what each system stores, and whether the task's owner changes when work changes hands. A central dashboard that displays a referral does not establish that a local user can act on it appropriately.

Verify the multi-instance connection, not an integration logo

For each connection, ask for the proposed environment, available operations, mapping owner, evidence of write success, and recovery procedure. Separate reading a record, attaching a document, updating a status, and confirming an appointment.

Use identifiers in the test report. If the same synthetic patient exists in two test instances, staff should be able to see which instance and local record a transaction targets. Do not accept a name alone as proof.

Then test a partial failure. One instance becomes unavailable while the others continue. Which work pauses? Who sees the outage? How are pending updates reconciled after recovery?

Avoid requiring one technical architecture simply because it sounds cleaner. A solution with separate instances may still fit if central visibility, permissions, exports, and handoffs meet your requirements. A single interface may still fail if it obscures the destination of an update.

Use the referral RFP question bank to capture written answers. Keep the detailed network scenarios in an attachment so reviewers can see exactly what the answers were tested against.

Demonstrate central, local, and overflow work

Ask a working coordinator to perform the demonstration tasks. Their assignment should reflect the team model you intend to operate.

For central teams, test site context, cross-site filters, destination visibility, and backup responsibility. For local teams, test whether the user can complete their work without navigating unrelated locations. For hybrid teams, inspect the transfer between central and local ownership.

A handoff test should have an explicit receiving action. If the first team marks work transferred, does the second team's queue contain it? Does the original team retain an unresolved handoff if assignment fails?

Test a staff absence too. Reassign a batch, preserve the previous owner in history, and verify that the backup receives the necessary context. Do not let the demonstration end after the administrator clicks “reassign.”

The organizational decision about what should become central belongs in standardizing acquired clinic operations. Here the question is whether the proposed software supports the model your organization has chosen.

Make the network dashboard prove its totals

Ask the vendor to show the underlying records behind one site number, then the network total. Use a small synthetic dataset with known expected results.

Hypothetical reconciliation test: Site A has 80 eligible referral episodes and 48 bookings. Site B has 20 episodes and 16 bookings. Their rates are 60% and 80%. The combined rate is 64 divided by 100, or 64%, not the unweighted average of 70%.

A system may correctly display both site rates and still calculate a misleading summary. Inspect the aggregation rule, exclusions, and observation window.

Now move an episode between sites. Decide whether the network reports it by originating site, receiving site, current owner, or another documented attribution. All can answer different questions. The problem is mixing them without labels.

Ask how corrections affect prior reports. If two records are later linked as duplicate receipts, can an evaluator identify why the total changed? Compare receipt date, last-update date, and reporting date.

The multi-site leakage measurement guide addresses deeper comparison design. For selection, require a transparent data trail and clearly label unavailable information.

Price the second wave before approving the first

Request an effort estimate for an additional site from each variation group. Include buyer hours, vendor configuration, interface access, staff preparation, and report mapping.

Ask which work can be reused. A reusable configuration should come with a description of what still requires local validation. “Clone the pilot” is incomplete if the next location has a different queue owner or record mapping.

Also ask what happens when a site changes EHR or leaves the shared operating model. Record the export, reassociation, and open-work transition requirements. These are deployment-fit questions even when no migration is planned this quarter.

Keep the rollout promise separate from the operational implementation plan. Selection evidence establishes what needs to be delivered; implementation evidence establishes that it has been delivered.

Use a coverage decision, not a single confidence score

Summarize fit by variation group. For each group, state whether its necessary scenarios passed, what remained untested, and how unresolved conditions would be handled.

A fictional summary might say: “Instance A demonstrated receipt, document linking, and status writeback. Instance B demonstrated receipt but awaits writeback testing. Instance C requires a priced interface assessment. Central overflow passed; local override inheritance remains untested.”

That is more decision-ready than “multi-site ready: 85%.” It gives procurement and operations a scope they can accept, narrow, or return for evidence.

Document why an untested condition is acceptable if you decide to proceed. The condition should have an owner, a test, and a point beyond which rollout will not expand without resolution.

Use the evidence to evaluate referral coordination software. The purpose is a justified network fit decision, not a successful flagship demonstration.

FAQ

Sources

• Luma Health product specifications, first-party example of a vendor documenting what its basic package includes.