Referrals

Close the referral black hole. The Referrals module makes every specialist referral a trackable, bidirectional, standards-based exchange — from outbound creation with a USCDI v3 clinical bundle attached, through closed-loop status tracking (Sent → Received → Scheduled → Consult Complete), to the consult report arriving back in the chart automatically. An insurance-aware referral finder surfaces in-network specialists. Transport uses FHIR ServiceRequest over Direct Trust with TEFCA fallback. Because REV.health is the single platform spanning all of a patient's care relationships, every referral exchanged enriches the same global clinical record.

Key Capabilities

Referral Creation with Clinical Context

One screen. Under sixty seconds. The provider selects a patient, enters a reason, sets urgency (Routine / Urgent / Emergent), and picks a specialist from the directory. The system automatically assembles a USCDI v3 clinical bundle from the patient's global record — conditions, medications, allergies, lab results, imaging, immunizations, care plans, procedures, vital signs, and social history — and attaches it to the referral. The provider signs and sends. No fax machine, no missing context.

Specialist Search / Referral Finder

The specialist directory is populated from NPPES data, payer Provider Directory APIs, and per-practice manual curation. Each entry includes the specialist's NPI, Direct address, TEFCA endpoint URL, and insurance network affiliations. Insurance-aware routing filters the directory by the patient's active in-network plan from the Eligibility module — only in-network specialists are surfaced as recommended targets. Out-of-network options appear with a clear warning. When a referral requires prior authorization, the flag routes to Payer Optimization for concurrent PA processing.

FHIR ServiceRequest over Direct Trust

Outbound referrals are transmitted via Direct Trust to the specialist's Direct address using FHIR ServiceRequest/Task resource payloads. When the receiving specialist has no Direct address on file, the system falls back to TEFCA-based exchange using the specialist's QHIN endpoint — the referral is transmitted as a FHIR ServiceRequest bundle and FhirServiceRequestID is stored for traceability. Both channels are first-class; referrals are bidirectional by default.

Closed-Loop Status Tracking

Every referral follows a state machine with full audit: Created → Sent → Acknowledged → Scheduled → Completed → Report Received. Each transition automatically creates a ReferralStatusHistory row recording the actor, timestamp, and new status. The referral coordinator's worklist surfaces stalled items — referrals that haven't been acknowledged within a configurable threshold trigger escalation alerts. The loop is closed when the consult report arrives and is filed back to the clinical record. A referral can be Cancelled from any pre-completion state; once Report Received, the referral is closed-loop.

Follow-Up Request Routing

When the specialist responds to a referral — accept, decline, or request modification — a ReferralResponse row is created with the response type, narrative, and appointment date. Accept moves the referral to Acknowledged; decline notifies the coordinator for rerouting; modify routes back to the referring provider for review. Inbound responses are auto-parsed from Direct Trust messages into structured fields — ≥ 90% of inbound referrals auto-parsed with no re-keying. Consult reports flow back through the same Direct Trust channel and are filed as clinical notes in Clinical Documentation.

Persona Connections

Technical Highlights

Delivery Phases

Phase 1 — Fax & Phone Baseline + Manual Tracking
Referrals are managed by fax and phone call. The provider fills out a referral form, the coordinator faxes it to the specialist, and tracks status in a manual worklist. The Referral entity and ReferralStatusHistory audit trail ship for internal tracking. The SpecialistDirectory is populated from NPPES data with manual curation. Outbound creation captures referral reason, urgency, and target specialist — but transport is fax/phone. Inbound responses are re-keyed manually. Closed-loop tracking is aspirational; the state machine is documented but not automated.
Phase 2 — Direct Trust + Closed-Loop + USCDI Bundle
Direct Trust transport is live via HISP integration (Kno2/Updox). Outbound referrals are sent as FHIR ServiceRequest payloads with USCDI v3 clinical bundles attached automatically. Inbound responses are auto-parsed into structured ReferralResponse fields — ≥ 90% auto-parse with no re-keying. Closed-loop state machine is fully automated: every transition creates a ReferralStatusHistory row. The referral coordinator worklist surfaces stalled items with escalation alerts. Insurance-aware routing filters the specialist directory by the patient's active in-network plan. Patient-facing referral visibility is available through the Patient Portal. Standing referrals support chronic care (e.g., 12 PT visits over 6 months). Referral creation target: < 60 seconds from intent to send.
Phase 3 — TEFCA Fallback + Analytics + Multi-Org
TEFCA-based referral exchange extends reach beyond Direct Trust coverage — when a specialist has no Direct address, the referral routes through the QHIN sub-participant endpoint. Referral analytics dashboard provides completion rates by specialty, average time-to-report, stalled-referral heat map, and top referring providers. Referral template library ships with pre-built templates by specialty. Multi-org referral aggregation — when a patient sees providers at multiple REV.health practices, the referral worklist aggregates across orgs into a single patient-wide view.

Success Metrics

Module Dependencies

Try This in the Demo

Developer Reference — Entity schemas (Referral, ReferralResponse, SpecialistDirectory, StandingReferral & more), state machine, RBAC, and functional/non-functional requirements: Referrals Dev Spec →