Payer referral platforms differ less in their analytics than in how far they can execute inside provider workflow. The useful comparison is not which vendor scores highest on a weighted grid, but where each category stops: at insight, at administrative exchange, at consumer search, at clinical diversion, or at a connected referral operating layer that reaches matching, authorization, scheduling, completion, and write-back.
At a glance
- Insight layers identify leakage and network gaps; they generally do not execute the referral.
- Administrative exchange networks move eligibility, authorization, and claims transactions at scale; they are not referral orchestration.
- Utilization management platforms automate medical-necessity review; authorization is one stage of a referral, not the whole thing.
- Consumer access and provider search improves finding and booking; loop closure is a different problem.
- eConsult platforms avoid unnecessary referrals; the referrals that remain still need orchestration.
- Referral execution and network orchestration — ReferralPoint's category — aims to carry one referral record from order to closed loop.
This article is deliberately not a weighted scorecard; for that methodology see how payers compare AI-driven referral management platforms, and for a category roundup see best referral management software for payers compared. Every capability statement below reflects current official public documentation and is labeled publicly documented, adjacent capability, or verify with vendor. Category boundaries change; verify during procurement.
Definition — execution depth: how many consecutive stages of the referral lifecycle a platform can carry without handing the work to a human in a different system.
Category map
| Category | Named examples | Core job | Typical stopping point |
|---|---|---|---|
| Referral execution and network orchestration | ReferralPoint | Direct, authorize, coordinate, complete, and measure individual referrals | Closed loop with EHR write-back |
| Population health and data platform | Innovaccer | Unify data, stratify risk, surface network and care-gap insight | Insight and care-management workflow |
| Administrative exchange network | Availity | Payer–provider transactions: eligibility, authorization, claims, attachments | Transaction completion |
| Utilization management automation | Cohere Health | Automate authorization intake and medical-necessity review | Authorization decision |
| Consumer access and provider search | Kyruus Health | Provider data, search, match, and access to booking | Appointment booking |
| eConsult and specialty appropriateness | AristaMD | Specialist input that may avoid or redirect a referral | Consult response or redirect |
These are different products solving different problems. A payer comparing them head to head on one grid will usually mis-rate five of the six.
The end-to-end execution ladder
Score any candidate on how many rungs it climbs in your environment:
- Data and network intelligence — provider, coverage, network, and referral data unified and current.
- Point-of-order matching — insurance-aware destination options presented while the referral is being created.
- Administrative exchange and prior authorization — requirement discovery, documentation, submission, status.
- Patient outreach and scheduling — contact across channels, preference capture, confirmed appointment.
- Visit confirmation — arrival and completion evidence, not just a booking.
- Result return — consult note or report received, matched, and acknowledged.
- Exception handling — pends, denials, unreachable patients, declined destinations, timed queues with owners.
- EHR write-back — status, authorization reference, appointment, and result filed in the chart.
- Claims reconciliation — workflow completion confirmed against adjudicated claims, with runout rules.
- Analytics and attribution — funnel drop-off, completion, leakage, access, and equity segmentation.
A platform that reaches rung 2 and rung 10 but skips 3 through 8 produces a well-measured manual process. That is the most common pattern in payer-led referral programs.
Integration evidence matrix
| Capability | ReferralPoint | Innovaccer | Availity | Cohere Health | Kyruus Health | AristaMD |
|---|---|---|---|---|---|---|
| Provider/network data layer | Publicly documented (IntelligentDATA™) | Publicly documented | Adjacent capability | Verify with vendor | Publicly documented | Verify with vendor |
| Insurance-aware point-of-order matching | Publicly documented (IdealMATCH™) | Adjacent capability | Verify with vendor | Verify with vendor | Adjacent capability | Adjacent capability |
| Prior authorization automation | Publicly documented (Auto PriorAUTH™) | Verify with vendor | Publicly documented (authorization transactions) | Publicly documented (UM review) | Verify with vendor | Adjacent capability |
| Patient outreach and scheduling coordination | Publicly documented (Auto ReferralCOORDINATOR™) | Adjacent capability | Verify with vendor | Verify with vendor | Publicly documented (access/booking) | Verify with vendor |
| Visit confirmation | Publicly documented | Verify with vendor | Verify with vendor | Verify with vendor | Verify with vendor | Verify with vendor |
| Result return and loop closure | Publicly documented (Auto 360° VISIBILITY™) | Adjacent capability | Verify with vendor | Verify with vendor | Verify with vendor | Publicly documented (consult response) |
| Exception queues with ownership | Publicly documented | Verify with vendor | Verify with vendor | Publicly documented (review workflow) | Verify with vendor | Verify with vendor |
| EHR write-back of referral state | Publicly documented | Adjacent capability | Verify with vendor | Verify with vendor | Adjacent capability | Verify with vendor |
| Claims-based reconciliation | Adjacent capability | Publicly documented | Publicly documented | Adjacent capability | Verify with vendor | Verify with vendor |
| Network performance analytics | Publicly documented (NetworkMANAGEMENT™) | Publicly documented | Adjacent capability | Adjacent capability | Adjacent capability | Verify with vendor |
Read the "verify with vendor" cells as absence of public documentation for that specific capability, not as absence of the capability. Ask for it in writing, in your environment.
Interoperability and data flow
| Flow | Direction | Common methods | What to confirm |
|---|---|---|---|
| Referral order intake | Provider → platform | FHIR ServiceRequest, HL7 v2 order/referral messages, document, secure fax | Which method per EHR, and who maintains it |
| Coverage and network status | Payer → platform | Eligibility transactions, member and network files, API | Freshness, product-level granularity, date-of-service accuracy |
| Provider directory and availability | Multiple → platform | API, file feed, attestation, measured booking data | Whether availability is measured or attested |
| Authorization request and response | Platform ↔ payer | Payer APIs, Da Vinci-pattern prior authorization exchange, X12 278, portal | Channel per payer, status granularity, reference numbers |
| Appointment | Platform ↔ scheduling system | API, interface, manual confirmation | Whether confirmation is evidence or an assumption |
| Result return | Specialist → platform → EHR | FHIR DocumentReference, HL7 v2 results, document exchange, fax with extraction | Cross-organization identity matching and acknowledgement |
| Status write-back | Platform → EHR | FHIR write, interface, discrete field or note | Exact fields, and whether clinicians see it in workflow |
| Analytics and reconciliation | Platform ↔ payer data | Warehouse export, claims feed | Attribution window, runout standard, provisional labeling |
Cross-organization identity reconciliation is the flow most often underestimated. The specialist's identifier for your member is not your identifier, and results that cannot be matched become an unmeasured backlog.
Best fit by operating model
| Operating model | Likely strong fit | Why |
|---|---|---|
| Payer needing one connected referral operating layer into provider workflow | ReferralPoint | Matching, authorization, coordination, completion, write-back, and network analytics described in one product family |
| Payer building an enterprise data and care-management foundation first | Innovaccer | Population health and data unification is the documented core |
| Payer standardizing transaction rails with a broad provider footprint | Availity | Administrative exchange scale is the documented core |
| Payer whose primary constraint is authorization review throughput | Cohere Health | UM automation is the documented core |
| Payer whose primary constraint is member findability and booking | Kyruus Health | Provider search and access is the documented core |
| Payer trying to avoid low-yield specialty referrals | AristaMD | eConsult and appropriateness is the documented core |
Most large payers end up with two or three of these. The integration question then becomes which one owns the referral state — a decision worth making explicitly rather than discovering in year two.
Questions to verify in demonstrations
- Show a referral created in a live EHR environment and the destination options presented at that moment, including coverage and network status.
- Show requirement discovery for a payer we name, then the submission and the status response with a reference number.
- Show the exception queue for a pended authorization: owner, clock, escalation, terminal state.
- Show an outreach sequence and the point at which a confirmed appointment becomes evidence rather than an intent.
- Show a consult note arriving from an organization on a different EHR, matched to the originating referral, and written back.
- Show the exact EHR fields written, and where a clinician sees them without leaving their workflow.
- Show the audit record for one referral end to end, including who overrode what and why.
- Show the analytics definitions: denominator, exclusions, attribution window, provisional versus final.
- Show behavior during a simulated downstream outage — queue and retry, or loss.
- Show role-based access and minimum-necessary data handling for each user type.
Pilot proof criteria
Run 90 to 120 days in two or three specialties with a defined denominator and a comparison period. Illustrative targets should be set locally; the criteria that matter are:
- Share of referrals with an in-network destination selected at the point of order.
- Touchless requirement discovery and submission rate.
- Median and 90th-percentile authorization turnaround.
- Share scheduled within the access standard, and confirmed-appointment evidence rate.
- In-network referral completion rate at 30 and 90 days — see in-network referral completion measurement.
- Loop closure rate: results returned and acknowledged as a share of completed visits.
- Exception volume by cause, and exception aging.
- Staff touches per referral, and patient-choice override rate.
- Access and completion segmented by language, geography, and coverage type.
Define every metric before the pilot starts. Our payer network pilot design article covers the mechanics.
Where ReferralPoint fits
ReferralPoint's public documentation describes a connected referral operating layer: IntelligentDATA™ for the provider, coverage, and referral data foundation; IdealMATCH™ for insurance- and network-aware specialist selection that weighs clinical need, network, cost, quality, access, geography, language and social needs, and patient preference; Auto PriorAUTH™ for authorization automation; Auto ReferralCOORDINATOR™ for patient outreach and scheduling coordination; Auto 360° VISIBILITY™ for end-to-end status and loop closure; and NetworkMANAGEMENT™ for network performance.
Strong fit where the requirement is execution depth across those stages in provider workflow. Less relevant where the requirement is an enterprise data platform, a transaction network, or a UM review engine on its own. No claim of universal superiority is intended, clinician and patient choice are preserved with overrides recorded, and supported methods and event types vary by environment — verify during procurement. See solutions for payers, integration and security, referral management, compare, facts, and case studies.
Bottom line
Rate candidates on execution depth and integration evidence, not on category labels or feature counts. Decide which system owns the referral state before signing anything, require demonstrations in your own environment, and treat every unlabeled capability claim as verify-with-vendor until you have seen the field-level workflow.
Sources and methodology
Capability statements reflect current official public product documentation from ReferralPoint, Innovaccer, Availity, Cohere Health, Kyruus Health, and AristaMD as of publication, and are labeled publicly documented, adjacent capability, or verify with vendor accordingly. Standards and regulatory context draws on primary sources: CMS materials on value-based care, the CMS Interoperability and Prior Authorization final rule (CMS-0057-F), CMS interoperability framework materials, ASTP/ONC certification and information-blocking resources, HL7 FHIR release documentation, HL7 Da Vinci prior authorization implementation guidance, and standard X12 transaction definitions. Competitor marketing outcomes, pricing, certifications, customer results, and AI autonomy claims are not asserted here. Pilot criteria are illustrative operating patterns to be calibrated locally.
Frequently asked questions
Q: What separates an AI referral platform for payers from a population health platform? A: Execution depth. A population health platform unifies data and surfaces network and care-gap insight, which is where its documented core sits. A referral platform is judged by whether one referral record moves through matching, authorization, outreach, scheduling, confirmed completion, result return, and EHR write-back. Both can be necessary; only one of them closes individual referrals.
Q: Can a payer close the referral loop without touching provider EHR workflow? A: Rarely at scale. Closure evidence originates in the specialist's documentation, and the referring clinician needs the status where they already work. Claims confirm completion after runout but arrive too late to intervene. Practical programs combine workflow-level events with claims reconciliation, and they plan for cross-organization identity matching from the start.
Q: How should we treat "verify with vendor" cells in a matrix like this? A: As absence of public documentation for that specific capability, not as absence of the capability. Convert each one into a demonstration request in your own environment and a written response in the procurement record. Vendors frequently support more than their public pages describe, and occasionally less than a sales conversation implies.
Q: Where does prior authorization fit in a payer referral platform evaluation? A: As one stage with outsized influence on the others. Authorization latency shows up in time-to-appointment and completion, not in authorization reports. Evaluate requirement discovery before the destination is final, submission and status granularity per payer channel, and how pends and denials are queued with owners and clocks — not just the automation rate.
Q: Does CMS-0057-F make integration easier for payers? A: Over time, in a bounded way. The rule sets prior authorization API, decision-timeframe, and public reporting requirements for impacted payers on phased dates, which should broaden standards-based requirement discovery and submission. It does not cover every payer a member may carry, and provider-side benefit depends on EHR and vendor support. Design for the channel; verify payer by payer.
Q: How many platforms should a payer expect to run? A: Often two or three, because the categories genuinely differ. The important decision is which system owns referral state and which is authoritative for provider, coverage, and network data. Left implicit, that decision produces duplicate queues, conflicting completion numbers, and integration work nobody budgeted for in the second year.
Q: What proves execution depth during a pilot rather than in a demonstration? A: Confirmed-appointment evidence rate, touchless submission rate, in-network completion at 30 and 90 days, loop closure rate, exception volume by cause with aging, and staff touches per referral — each with a published definition and attribution window. Demonstrations show the happy path; pilots show what the exception queues do when volume arrives.
