Referral Management System Migration: Keep Open Referrals Accounted For

Define what is moving and what continues

Replacing a referral application can leave the EHR, fax service and scheduling system in place. Write down that boundary before discussing export files. The migration team needs to know which system will create referrals, assign tasks, contact patients and confirm administrative outcomes after cutover.

Separate three destinations: active work in the replacement application, historical information available through an approved access arrangement, and unresolved items awaiting reconciliation. An attachment stored for reference does not become a worked task simply because it is accessible.

ONC's Health IT Playbook discusses migration between electronic environments and the importance of integrating and accessing historical data. Its scope is EHR migration; the referral-work manifest below is an original operational method for a narrower system change.

Name a migration lead, a source-system owner, a destination-system owner and the operational teams accepting work. Assign the unresolved queue too. A vendor can confirm an import while staff still cannot determine which referral needs action next.

For first-time rollout phases, use the referral automation implementation plan. Here, the starting point is a live process with work already underway.

Build the open-work migration manifest

Choose an inventory timestamp and capture every in-scope active episode as of that point. Record the query or filter used to create the inventory. Include records hidden by local views, inactive staff assignments or unusual status values if they still contain unfinished in-scope work.

Use one row per referral episode, with linked task and document records where necessary. A referral can contain several open tasks, so a flat export with one status column may be insufficient.

Keep the manifest in an organization-approved environment. Use synthetic records for preparation and demonstration, then apply authorized handling arrangements to the actual migration.

Record how totals will reconcile before anyone changes a record. If the source contains duplicate representations of one episode, document the relationship and correction separately. Reducing the number of imported rows is not evidence that referrals have been completed.

Translate status meanings before loading records

Compare what the source and destination labels prove. "Complete" might mean that intake finished in one application and that an appointment occurred in another. Copying the word across would manufacture a different outcome.

For each source state, capture its entry evidence, outstanding responsibilities, target representation and any information that cannot be represented directly. Preserve unresolved parallel tasks even when the main episode has progressed.

For example, a source record labelled "scheduled" may have a confirmed appointment and an outstanding administrative document request. The destination needs both facts. Converting everything to one closed state would hide the request; converting everything to pending would hide the booking.

The referral tracking state dictionary provides the ongoing record design. Migration adds the translation between two existing designs and the evidence that no meaning was lost.

Identifiers need the same care. HL7 FHIR distinguishes a resource's logical location and ID from business identifiers that identify the underlying concept across systems. A new system ID should not erase the source reference needed to connect the history.

Do not match episodes using patient identity alone. The same patient can have multiple referrals. Use the approved matching method and preserve uncertain associations for review rather than choosing whichever record looks closest.

Test a complete work packet

A migration sample should exercise relationships, not just individual fields. Include an episode with a pending callback, one with a confirmed booking, one with supplemental documents, and one whose record association is unresolved.

For each synthetic packet, ask a receiving coordinator to find the episode, inspect the evidence and identify the next action. The coordinator should not need the migration specialist to explain an unfamiliar state or retrieve an attachment from an export folder.

Test document usability separately from document counts. Confirm that the expected document opens, belongs to the intended episode and retains the context needed for the administrative task. A list containing ten filenames does not prove ten usable documents arrived.

Inspect the old-to-new references in both directions. Starting with a source item, find its destination. Starting with a destination item, identify its source and migration result. This catches an import that looks complete from one side but cannot explain where particular records went.

Use referral intake reconciliation for the ongoing arrival process. The migration exercise should test how new intake joins existing episodes during the transition, rather than create a second definition of a referral.

Reconcile the interval between export and cutover

The opening export is a snapshot. Decide how the team will capture new episodes, changed assignments, new documents, bookings and legitimate closures after that timestamp.

Write the cutover rule as an operational sentence: "From the recorded handoff time, team B works accepted destination records; named contingency staff retain the listed unresolved items." Adapt it to the actual arrangement, including how incoming work is received while the transfer is being checked.

Track changes to existing episodes separately from new episodes. A booking added after export changes an existing record. It is not another referral. A supplemental document should update the linked work, not automatically start a new episode in the destination.

Maintain one accountable process for each action. If both systems can trigger patient contact, define which actor is active and how the other is prevented from sending the same request. Observation in both systems does not require execution in both.

After the first import, reconcile the change interval and inspect uncertain writes. A timeout is an unknown outcome until the destination is checked. Repeating an action without that check can leave two records or two active tasks for the same intended work.

Work through a reconciled cutover example

Hypothetical example: a practice inventories 480 unique active referral episodes on Friday afternoon. It uses a Monday cutover checkpoint. These counts illustrate accounting, not a recommended migration timetable.

The first test import produces 420 correctly linked and assigned episodes. Twenty-five need association review, 20 lack a required supporting document in the destination, and 15 lack an accepted receiving owner. The categories are mutually exclusive for this example and total 480.

Between the inventory and checkpoint, 40 new episodes arrive. Among the original 480, staff record 12 supported administrative closures, 16 new bookings and 10 supplemental-document updates. In this example those changed groups are distinct. Only the 40 new episodes increase referral volume; the other events update existing episodes.

After reconciliation, the team accounts for the work as follows. The middle column shows accepted destination work + open reconciliation items + supported closures for each cohort.

The combined inventory is 480 + 40 = 520 episodes. Active work at the checkpoint is 520 minus 12 supported closures, or 508. That active work consists of 479 accepted destination episodes plus 29 reconciliation items.

The 16 bookings and 10 document updates must be reflected in the relevant records, but are not added again to the 520. A report that counts them as new referrals would inflate the inventory by 26.

The migration is not finished. The 29 unresolved episodes remain in the approved contingency process with named owners and next actions. The team can assess whether its pre-agreed cutover conditions allow the accepted group to proceed, but it cannot call all 508 active episodes successfully migrated.

Make the first operating review about missing work

Review the accepted records from the perspective of the next shift. Can covering staff see pending tasks, overdue follow-up and the correct appointment references? Can they explain why a migrated record is open without consulting the old coordinator?

Compare worklist totals with the manifest, then inspect discrepancies. A count can change because a filter excludes a team, a source update arrived late, or work progressed. Keep those explanations separate.

Preserve original timestamps in reporting. Importing an old referral on Monday should not make it a Monday referral in the receipt cohort. Mark the migration boundary in operational reports when a changed definition or missing history prevents comparison. The referral dashboard guide explains the definitions those comparisons depend on.

Close each reconciliation item with evidence of its outcome. Moving an unresolved item into another spreadsheet is a handoff, not resolution. Keep the responsible owner and the remaining action visible until the receiving arrangement is accepted.

Decide when the old workflow can retire

Separate stopping production actions from ending historical access. The old application may stop creating tasks while approved historical access remains necessary. Your organization's records, security and contracting owners should supply the applicable arrangements; this worksheet does not set retention periods.

Ask for a final acceptance record covering active work, unresolved exceptions, source-to-destination references, needed history, incoming channels and remaining vendor responsibilities. If an item depends on continued access, name the owner and the actual access method.

Use the referral management RFP questions to examine export and transition capabilities before a future purchase. At cutover, the practical standard is simpler: every in-scope episode has an explained disposition, and every unfinished task has an accepted operational home.

Explore the administrative workflow around referral coordination software.

FAQ

Sources

• ONC Health IT Playbook: Electronic Health Records, section 1.5, "Migrate your data". Electronic-environment migration and historical-data access.
• HL7 FHIR R4: Resource identity, business identifiers. Logical identifiers and business identifiers across systems.