Referrals Decision Guide | Medplum
On this page
Companion to the Referral Management docs.
Section 1: Use Case & Participants
1.1 Which side(s) of the referral lifecycle do you build for?
- Outbound only – you originate referrals to others
- Inbound only – you receive referrals from others
- Both
1.2 Who interacts with referrals, and is the patient part of the workflow?
- Sending side: which roles author, edit, and send referrals (clinicians, MAs, coordinators, intake staff)?
- Receiving side: which roles triage, accept, and work referrals on intake?
- Patient: do patients see referrals, get notified, or take action (e.g. view in portal, self-schedule, decline)?
1.3 Where do receiving providers live relative to your tenant?
- Inside your tenant only
- Partner tenants or organizations
- External organizations without FHIR connectivity
- Some combination
1.4 Is this a new build or replacing/extending something, and what other systems must it work with?
- If replacing: what system or workflow, and what gaps drove the change?
- If new: is referrals central to the product or additive?
- What other systems will referrals flow to or from (source EHR, downstream EHRs at receivers, billing, HIE, payer portals, include DirectMessage)?
Section 2: Feature Scoping
Go through each row together. For each cell under Yes / No / Nice-to-have / Not sure, mark the customer’s answer. The § column points to the deep-dive subsection that covers each feature.
| # | Feature | § | Yes | No | Nice-to-have | Not sure |
|---|---|---|---|---|---|---|
| 1 | Multiple referral forms by specialty (vs one generic form) | 3.2 | ||||
| 2 | Tie every referral to the visit where it was created | 3.2 | ||||
| 3 | Pull in chart context automatically when sending (recent labs, problems, meds, allergies, coverage) | 3.4 | ||||
| 4 | Different audiences for notes on the referral – patient, receiving provider, internal staff, or mix | 3.4 | ||||
| 5 | Maintain your own directory of referral recipients (clinicians, sites, queues) in Medplum, vs sourcing from another system | 3.3 | ||||
| 6 | Send referrals to recipients outside your product (printed or PDF summary, care-summary document, fax, secure messaging, email) | 3.5 | ||||
| 7 | Accept referrals from outside (fax or scanned mail, secure inbox, Direct Message, care-summary drops, API or health-information exchange, typed in by staff) | 3.6 | ||||
| 8 | Route / assign referrals and track work on open referrals (intake pools, ownership, aging or SLA dashboards) | 3.7 | ||||
| 9 | Prior authorization workflow (eligibility checks, payer auth submissions before scheduling) | 3.7 | ||||
| 10 | In-network / coverage check against patient insurance when selecting or verifying a recipient | 3.3 3.7 | ||||
| 11 | Custom status steps for where the referral sits in workflow (e.g. sent → accepted → scheduled → done) | 3.8 | ||||
| 12 | Tie results and visit notes back to the original referral so the thread stays complete | 3.9 |
Section 3: Feature Deep Dives
Cover each feature flagged Yes or Nice-to-have in Section 2. The goal is to land on a clear recommended approach by the end of each section.
Referral Resource
3.1 Referral Semantics – Type, Coding, Intent, Priority
Each referral is one ServiceRequest. Decide how you classify it, how urgency is expressed, whether you expose a staff-facing reference number, and whether drafts exist before send.
Questions:
- How do you classify referrals (specialty, service, program), using standard codes, your own list, or both?
- What urgency options do users pick, and should they match triage and reporting?
- Do you show a referral number or reference beyond the system id?
- Is the referral final at send/commit, or do you need a draft first?
| Situation | Approach |
|---|---|
| Category and service type | Bind category / code to agreed ValueSets (SNOMED, custom, or mix); drives search and reporting. |
| Priority | Set ServiceRequest.priority; keep labels aligned with clinical operations. |
| Display referral number | ServiceRequest.identifier with your namespace; assign at create when needed for ops or correspondence. |
| Default – signed at send | intent = order when the referral is transmitted or committed. |
| Draft before release (less common) | intent = proposal until release, or hold draft state outside FHIR until create – align with compliance and audit needs. |
Sending Referrals
3.2 Capture Flow – Form Library & Originating Context
Decide how referral intake is structured in the UI – one flow vs several by specialty or program, how answers are constrained, and whether every referral must link to an originating visit.
Questions:
- Do you use one referral intake flow for everyone, or different flows by specialty, service, or program?
- Which fields must be chosen from lists or structured inputs (e.g. specialty, recipient, urgency), which allow free text, and what is required before the referral can be sent?
- Must every referral tie to the visit where it was created, or can referrals start without a linked visit (e.g. intake, triage, outreach)?
| Situation | Approach |
|---|---|
| One form | One Questionnaire; Bot maps to one consistent ServiceRequest shape. |
| Specialty forms | Multiple Questionnaires; shared core fields + specialty-specific items; map each to ServiceRequest. |
| Encounter required | Require encounter when referrals always start from a scheduled or in-progress visit. |
| Encounter optional | Allow missing encounter when referrals can start outside a visit; enforce subject and clinical reason instead. |
3.3 Recipient & Directory Model
Decide who users may send a referral to (person vs site vs queue) and where your recipient directory lives – maintained in Medplum, fed from another system, or both.
⚠ One-way door: If recipients start as free text and you move to a structured directory later, expect to reconcile historical referrals against the new directory.
Questions:
- Can a referral go to a specific clinician, to a site, department, or queue, or either, depending on referral type?
- Is your recipient directory edited and stored in Medplum, synced from another system, or mixed?
- Should the recipient picker show or filter by in-network status for the patient's coverage?
| Situation | Approach |
|---|---|
| Named individual | performer → Practitioner with display for UX. |
| Pool or department | performer → Organization or HealthcareService when the referral is to a group or queue. |
| Directory in Medplum | Maintain Practitioner / Organization / HealthcareService; forms use references or search-backed pickers. |
| External directory | Sync or resolve selections to FHIR references at submit time via Bot or integration. |
| Network-aware picker | Filter or label recipients by in-network status. |
3.4 What the Referral Carries – Notes & Clinical Package
Decide what leaves with the referral, how much is automated versus curated at send, and which audiences see each part of the narrative.
Questions:
- What clinical material must travel with the referral (reason for referral, problems or diagnoses, key meds and allergies, recent labs or imaging, coverage)?
- Should internal staff-only notes appear on the referral, or only content intended for the receiving provider and the patient?
| Situation | Approach |
|---|---|
| Receiver + patient messaging | note for receiving provider; patientInstruction for patient-facing instructions. |
| Lean vs rich package | Minimal reasonReference + short note vs broader supportingInfo and DocumentReference attachments. |
| Context at send | Auto-populate from chart where policy allows; let clinicians add or remove items before send. |
3.5 Outbound Transmission – Channels & Payload Format
Decide how referrals leave your product – whether recipients get structured exchange versus documents – and what you produce for each sending path.
Questions:
- Do any recipients accept referrals through structured exchange with your system?
- What outbound channels do you plan to use?
- For each outbound channel you plan to use, what do you actually send or generate?
| Situation | Approach |
|---|---|
| FHIR-capable peer | Send or expose ServiceRequest and related resources via API. |
| No FHIR API | Bot-generated PDF or C-CDA; attach or link via DocumentReference / Binary; log outbound Communication. |
| More than one channel | Keep one ServiceRequest as source of truth; run separate send paths per channel without divergent clinical content. |
Receiving Referrals
3.6 Inbound Intake – Channels & Ingestion
Decide how inbound referrals get created, reviewed, and matched to patients.
Questions:
- Which channels feed referrals into your product (e.g. automated exchange with a partner, fax, or scanned documents)?
- When inbound patient information is incomplete or inconsistent, how do you find or confirm the correct patient record?
| Situation | Approach |
|---|---|
| Structured FHIR inbound | Validate and persist ServiceRequest; acknowledge per your protocol. |
| Structured documents | Bot integrates and maps fields → ServiceRequest + related resources; retain source as DocumentReference / Binary. |
| Fax or scanned documents | OCR → abstract fields → map to ServiceRequest + source DocumentReference; human review when confidence is low. |
3.7 Working the Referral – Assignment, Authorization, Scheduling
After a referral is created or accepted, decide how it gets to the right person, what authorization and coverage steps gate the work.
Questions:
- Who picks up a new referral first – an intake pool, a department queue, or an assigned coordinator?
- Does the referral need to confirm in-network status or covered benefits for the patient's plan before scheduling?
| Situation | Approach |
|---|---|
| Ownership and assignment | Task.owner (and Task.requester for the originator); pool ownership via Organization / HealthcareService; reassignments preserve audit. |
| Check in-network status / covered benefits | CoverageEligibilityRequest with purpose: benefits; response returns network participation and benefit details. |
| Check whether prior auth is required | CoverageEligibilityRequest with purpose: auth-requirements; response indicates authorizationRequired and any supporting documentation needed. |
3.8 Lifecycle & Business Status Code System
Decide how you track a referral from request through completion – or cancellation – including naming those steps and handling cancel vs reroute.
Questions:
- Which milestones matter enough to show and operate on?
| Situation | Approach |
|---|---|
| Linear milestones | Few businessStatus codes; move Task.status with clear transitions. |
| External signals | Bots or subscriptions update businessStatus when external systems report acceptance or completion. |
| Cancel / reroute | Terminal or superseded Task with reason; consistent rule for updating ServiceRequest.performer vs new referral. |
3.9 Results & Closure Round-Trip
Decide what should come back after the referral is acted on, how those items attach to the right referral, and what counts as done for the referring side, the receiving side, or both.
Questions:
- After the referral goes out, what do you expect back?
| Situation | Approach |
|---|---|
| Labs / imaging | DiagnosticReport with basedOn → ServiceRequest. |
| Completed specialist visit | Encounter with basedOn → ServiceRequest. |
| Narrative / PDF reply | DocumentReference with context pointing at the referral. |
| Linking | Manual selection or automated match using identifiers you control. |