Recover referral import errors with a fictional behavioral health batch-control exercise, partial-success cases, retry decisions, and buyer tests.
A referral import recovery worklist should explain each submitted row’s outcome and the evidence needed before correction or retry, so partial success does not create missing requests or duplicate demand.
An import can finish with some accepted rows, some rejected rows, and some outcomes the receiving team cannot yet establish. Retrying the whole file may create duplicates, while treating the completion message as full success can lose requests. Buyers should test the recovery path with a deliberately imperfect synthetic batch.
Behavioral health crm referral import errors recovery
Define the unit submitted and the unit created. A source row may represent a person, a service request, a document, or an update; those are not interchangeable. The recovery exercise should preserve the source reference, submitted content context, receiving result, and unresolved question. It should not assume that an importer is idempotent or that a particular integration exists.
Reconcile a fictional 12-row batch
The batch submits 12 referral rows. Eight have confirmed accepted outcomes, two have confirmed validation failures, one is flagged for possible duplication, and one has an unknown result after an interrupted response. The control total is 12 = 8 + 2 + 1 + 1. Accepted does not necessarily mean a new person was created or an appointment was offered. Define what acceptance establishes in the proposed implementation before counting demand.
Correct the rejected rows at the source fact
One failed row contains an invalid service code and another lacks an agreed required identifier. Staff should correct the supported fact through the approved source or transformation process, with clarification where needed. Do not insert a convenient placeholder simply to pass validation. Clinical service mapping requires the appropriate clinical or program review. Preserve the original failure context so a later reviewer can understand why the row changed.
Investigate uncertain success before retry
The unknown row may already have created a request despite the interrupted response. Use the actual supported receiving evidence to establish its outcome. A proposed lookup or duplicate check needs a demonstrated method; do not promise a universal automatic retry protection. The possible-duplicate row also needs reviewed identity and request context. Matching a person does not necessarily mean the service request is a duplicate.
Test recovery without losing control totals
After correcting two rows, resubmit only what the approved recovery process identifies as appropriate. Retain the relationship between the original row and the recovery result. A second attempt is another submission event, not necessarily new referral demand. The final report should explain every original row, including unresolved outcomes, rather than lowering the denominator to the rows that eventually imported cleanly. Store any working files using the organization's approved data-handling process.
Work through the fictional acceptance exercise
Use a 12-row batch-control and recovery worklist with accepted, rejected, possible-duplicate, and unknown-result cases, including a partial-success retry drill. All examples below are fictional.
| Exercise | Starting evidence | Required action | Failure to expose |
|---|---|---|---|
| Invalid service | One row contains a service code the receiver rejects | Verify the intended service before correcting the mapping | An arbitrary valid code makes the import pass |
| Missing identifier | One row lacks an agreed required identifier | Clarify the actual source fact | A placeholder becomes a false identity fact |
| Unknown result | The response fails after a row may have been accepted | Investigate receiving evidence before retry | The whole file is retried as though nothing succeeded |
| Possible duplicate | The person exists but the service request may be new | Review person and request identity separately | An existing person causes legitimate demand to be discarded |
Boundary 1: Invalid service
Technical acceptance should not be achieved by changing the meaning of the request without the required review.
Boundary 2: Missing identifier
A complete-looking row can be less trustworthy than an explicit unresolved failure.
Boundary 3: Unknown result
Partial success creates a duplication risk that must be evaluated using actual demonstrated behavior.
Boundary 4: Possible duplicate
The unit created by the import matters. One person can have more than one valid service request.
An interrupted result turns out to be accepted already
The 12-row batch initially has eight confirmed accepted rows, two validation failures, one possible duplicate, and one unknown result. The unknown row, R-12, lost its response after submission. Its presence in the worklist means neither failure nor success has yet been established.
The supported receiving investigation finds R-12's request and confirms it was accepted during the first submission. The control total becomes nine accepted, two rejected, one possible duplicate, and zero unknown: still 12 original rows. R-12 is not resubmitted.
The two rejected rows are corrected using verified source facts and accepted on their recovery attempts. The ledger now shows 11 accepted original rows and one still requiring duplicate review. There have been 14 submission events—12 original submissions plus two retries—but only 12 original candidate rows. The request and person totals still depend on what acceptance creates in this implementation.
The possible-duplicate review then establishes that the row concerns an existing request and is handled under the approved process without creating another request. Its disposition is linked to that existing request, rather than counted as a newly imported one. Retrying the complete file would have resubmitted nine already accepted rows before the corrections even began. Counting 14 submission events as demand would likewise inflate activity into requests. Row-level evidence prevents both mistakes without assuming automatic retry protection.
Observe the work before setting a target
AHRQ’s flowchart tool examines process handoffs.
AHRQ describes observation in simulated settings.
Run the deliberately imperfect synthetic batch in the proposed evaluation environment. Ask the receiving employee to reconstruct all 12 outcomes without a presenter translating error codes. Retry the corrected cases through the actual supported process and inspect the receiving records. The buying committee should retain the limits of retry protection, manual investigation needs, and source-data responsibilities as part of implementation scope.
Questions to settle with the buying committee
Does an import completion message prove every referral arrived? No. Establish the outcome for each submitted row, including partial acceptance, rejection, and unknown results.
Should a partially successful file always be retried in full? Determine the actual row outcomes and supported retry behavior first. Do not assume automatic duplicate protection.
Can a placeholder fix a missing required identifier? Use supported source facts and the approved clarification process. Passing validation does not justify inventing identity information.
Is an existing patient necessarily a duplicate referral? No. Review both person identity and the particular service request. An existing person can have a legitimate new request.
Bring the specimen to a full-platform review
Use the batch-control worklist in the technical and admissions review. The buyer should see a concrete recovery process whose limits are understood, with every submitted row still accountable after a partial failure.
Ease offers a unified CRM, EHR, and RCM platform for behavioral health. Before approving the import scope, ask CRM, EHR, and RCM reviewers which receiving evidence resolves an uncertain row and prevents an unsupported whole-file retry.
Related reading
- Marketing and Admissions: Reconcile Qualified Demand
- Group Openings: Match Referral Demand to Start Dates
Frequently Asked Questions
Does an import completion message prove every referral arrived?
No. Establish the outcome for each submitted row, including partial acceptance, rejection, and unknown results.
Should a partially successful file always be retried in full?
Determine the actual row outcomes and supported retry behavior first. Do not assume automatic duplicate protection.
Can a placeholder fix a missing required identifier?
Use supported source facts and the approved clarification process. Passing validation does not justify inventing identity information.
Is an existing patient necessarily a duplicate referral?
No. Review both person identity and the particular service request. An existing person can have a legitimate new request.
