Referral Partners: Report Access Without Counting Twice
Build referral-partner access reports with a fictional person-to-request bridge, shared-source cases, cohort definitions, and defensible outcome measures.
Referral-partner access reports should distinguish people, service requests, and referral events, then attribute each reported outcome using a stated rule that prevents shared referrals from becoming duplicate care.
Two partners may refer the same person, and one partner may send several documents about one request. A report that treats each event as a new person can exaggerate demand, access, and partner contribution simultaneously. The remedy starts with the report's unit and its attribution rule rather than a more elaborate chart.
Behavioral health referral partner access reports
Specify whether the report describes referral events received from a partner, distinct service requests associated with that partner, or distinct people reaching a milestone. All can be useful. They become misleading when presented as interchangeable counts or added together without accounting for shared relationships. Preserve uncertain source and identity cases rather than forcing every row into a convenient category.
Build a fictional partner bridge
Partner A sends six events concerning five requests. Partner B sends five events concerning four requests. Two requests appear in both partner groups. There are 11 events, nine partner-request relationships, and seven distinct requests across the organization. The calculation is five + four − two = seven. It does not establish seven distinct people because one person might have two service requests. A board total that simply adds the partner columns would overstate distinct requests.
Choose attribution before comparing outcomes
For an exclusive organizational total, use a documented rule such as the reviewed original request source, while retaining secondary relationships separately. For a relationship report, allow a request to appear under several partners but explicitly label the columns non-additive. Neither approach is universally correct for every business question. The rule should be stable enough that a partner name change or later document does not silently move historical outcomes.
Define access milestones narrowly
A partner might need to know whether a request was received, reviewed, offered an appointment, or reached attended care. Those are different outcomes. Establish what information can appropriately be shared under the actual arrangement; the report design does not itself grant permission to disclose details. Clinical suitability decisions remain clinician-owned. For aggregate comparisons, show unresolved requests alongside reached milestones so a higher outcome rate is not created by excluding difficult cases.
Compare like cohorts and expose late information
An October receipt cohort for Partner A cannot fairly be compared with all October attendance associated with Partner B. The latter may include requests received long before October. Use a common receipt period and cutoff when answering a referral-to-care question. If a late identity review joins two records, explain the restatement rather than silently rewriting the prior report. Keep the event count available when investigating why a partner's operational workload differs from the distinct-request total.
Work through the fictional acceptance exercise
Use an 11-event, seven-distinct-request partner bridge with both exclusive and non-additive relationship reporting views. All examples below are fictional.
| Exercise | Starting evidence | Required action | Failure to expose |
|---|---|---|---|
| Repeated document | Partner A sends a second document for an existing request | Retain the event without adding a new request | Every attachment creates another referral |
| Shared request | Partners A and B both identify the same reviewed request | Apply the stated exclusive or relationship rule | Both columns are added as distinct demand |
| Several services | One person has two different service requests | Preserve the person-to-request distinction | Two requests are reported as two people |
| Late identity review | A later review establishes that two records describe one request | Explain the revised denominator and cutoff | Historical totals change without explanation |
Boundary 1: Repeated document
The second event may be useful workload evidence, but it does not necessarily represent new demand.
Boundary 2: Shared request
The report must make shared relationships understandable before anyone interprets the organization-wide total.
Boundary 3: Several services
The operating report can count both requests while the people report counts the reviewed individual once.
Boundary 4: Late identity review
A valid correction still needs an understandable bridge from the earlier report to the revised population.
A newly recognized shared request changes the bridge
The initial partner bridge has five requests associated with A and four with B, with two reviewed shared requests. Nine partner-request relationships therefore represent seven distinct requests. The 11 received events include resends and do not establish 11 requests.
A later identity-and-request review finds that A's request A-5 and B's B-4 describe the same service request, previously counted separately. Each partner still has the same number of associated requests, but there are now three shared relationships. The organization-wide request total becomes five plus four minus three: six. The event total remains 11 because no received event has disappeared.
The report owner applies the declared exclusive attribution rule and places the newly linked request under A for the additive organization-wide view. B retains its relationship in the separately labeled non-additive view. The correction is shown as a restatement from seven distinct requests to six, with the reviewed match date and explanation.
Simply subtracting one from B's partner column would falsely suggest B never sent the request. Leaving the old distinct total would count the same request twice. Moving every B event to A would also erase the useful evidence of B's participation. The corrected report preserves the source activity while changing only the request identity and the dependent denominator supported by the review.
Observe the work before setting a target
AHRQ’s flowchart tool examines process handoffs.
AHRQ describes observation in simulated settings.
Ask admissions and a reporting analyst to reproduce the fictional total independently. Give one the partner event list and the other the reviewed request list. They should arrive at the same seven-request control total while explaining why partner relationships sum to nine. Then have the partner-facing team review the intended milestone language and permitted sharing. Retain both the report definition and the worked calculation as acceptance evidence.
Questions to settle with the buying committee
Can partner columns always be added together? No. Relationship views can contain shared requests. Label them non-additive or apply a documented exclusive attribution rule for an organization-wide total.
Does another referral document establish new demand? Not necessarily. Preserve the event and review whether it concerns an existing request, a new service request, or a separate person.
What belongs in a partner access rate denominator? State the chosen unit, receipt cohort, cutoff, and handling of unresolved cases. Use the same definition for the milestones being compared.
How should corrected identity matches affect prior reports? Explain any resulting restatement and preserve the relationship between prior and revised counts. Do not silently change historical attribution.
Bring the specimen to a full-platform review
Use the partner bridge to test whether the proposed workflow can explain source events and reached milestones together. The buyer's decision should rest on reproducible counts and appropriately scoped partner communication.
Ease offers a unified CRM, EHR, and RCM platform for behavioral health. Can CRM, EHR, and RCM reviewers reproduce the partner bridge after a shared-request correction without counting partner relationships as additional care?
Related reading
- Call Attempts: Measure Contact Without Inflating Access
- Intake Forms Changed Mid-Referral: Keep the Version
Frequently Asked Questions
Can partner columns always be added together?
No. Relationship views can contain shared requests. Label them non-additive or apply a documented exclusive attribution rule for an organization-wide total.
Does another referral document establish new demand?
Not necessarily. Preserve the event and review whether it concerns an existing request, a new service request, or a separate person.
What belongs in a partner access rate denominator?
State the chosen unit, receipt cohort, cutoff, and handling of unresolved cases. Use the same definition for the milestones being compared.
How should corrected identity matches affect prior reports?
Explain any resulting restatement and preserve the relationship between prior and revised counts. Do not silently change historical attribution.
