RCM & Billing Decision Guide

Companion to the Billing docs.

Section 1: Use Case & Participants

1.1 What is your reimbursement model?

• Insurance / claims-based – you bill payers and reconcile their responses
• Patient self-pay / cash – patients pay you directly; no payer claim
• Value-based / capitation – per-member-per-month or risk-based
• Some combination

Why: Claims-based reads every lane; self-pay skips the Charge → Claim → Payer lane; value-based leans on Foundations and the Value-Based lane (3.11).

1.2 How much of the revenue cycle runs in Medplum vs. delegated?

• Clearinghouse-direct – Medplum runs the cycle; the clearinghouse is transport. You own scrubbing, denials, and remittance posting. The most complete documented path.
• RCM-automation partner – you send encounter and charge data and delegate the back end; scrubbing, payer routing, denials, resubmission, patient collections, and reporting run on the partner’s platform. The integration surface is claim submission; the partner’s billing tasks sync back into Medplum as Tasks.
• Documents only (no electronic claims) – you don’t run claims through a clearinghouse or RCM partner. Generate a CMS-1500 PDF for the occasional paper/portal payer, or hand patients a superbill to self-submit for out-of-network reimbursement. Common for cash-pay and OON practices (see 1.1); also a per-payer fallback you can layer onto any engine above.
• External Practice Management (PM) / billing system – Medplum is the clinical source of truth; charges or claims hand off to an existing PM/billing system that owns the rest.

In one line: a clearinghouse moves your claims; an RCM platform runs your revenue cycle. Either way Medplum owns the front half (coverage, charge capture, claim assembly); the paths diverge on the back half.

How to choose:

Paths can mix. The choice sets which Section 3 lanes you build (3.5–3.10) vs. read only for the boundary.

1.3 Who does the billing work, and is the patient part of it?

• Charge capture: clinicians at point of care, or back-office entry?
• Coding and claim work: dedicated coders/billers, or automated with exception review?
• Accounts receivable (AR) follow-up: who works denials, aging, and patient balances?
• Patient: do patients see estimates, statements, or pay online?

Why: drives charge-capture design (3.5), who works denials and AR (3.8, 3.10), and whether patient-facing billing is in scope (3.9).

1.4 Where does coding happen, and how automated is it?

• Auto-derived from clinical data (visit type, orders, procedures)?
• Coder-reviewed before the claim is built?
• Fully manual?

Why: drives the coding and review model in charge capture (3.5) and where scrubbing exceptions surface (3.6).

1.5 New build or replacing/extending, and what else must billing touch?

• If replacing: what billing/PM system, and what gaps drove the change?
• If new: is billing core to the product (you’re building an RCM/billing product) or additive (a clinical app that also needs to bill)?
• What other systems must billing read from or write to (clinical/EHR source, PM, clearinghouse, accounting/GL, payment processor, payer portals)?

Why: surfaces integration boundaries and the source-of-truth split behind 1.2, 3.6, and 3.7. Core-to-product builds tend to own the cycle (a clearinghouse); additive builds tend to delegate (an RCM partner or external PM).

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.

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.

Section 3 is grouped into four lanes:

Foundations

3.1 Coverage & Insurance Model

How you represent a patient’s insurance (the coverage stack, the subscriber, payers, cost-sharing) is the foundation every claim and eligibility check builds on. See Representing Patient Insurance Coverage; coverage capture at intake is in the Intake guide (3.5).

Questions:

• Do patients commonly have more than one coverage, and must you bill them in order?
• Is the subscriber sometimes someone other than the patient?
• Is your payer list curated in Medplum, synced, or created on demand?
• What cost-sharing (copay, coinsurance, deductible) do you need for estimates and patient billing?

3.2 Account & Financial Ledger

Decide whether you track a patient financial account that rolls charges, claims, and payments into a balance (the backbone for AR in 3.10 and patient billing in 3.9), or let each charge stand alone.

Note: the rows below are one FHIR approach to a financial ledger; validate against your reporting and reconciliation requirements.

Questions:

• Do you need a single balance rolling up charges, payer payments, adjustments, and patient payments?
• Is the account scoped per patient, per visit, or per episode?
• Do you track payer and patient responsibility separately on the same account?
• Must the account reconcile against an external accounting/GL system?

Pre-service / Patient Access

3.3 Eligibility & Benefits

Decide whether you verify coverage before service, what you ask the payer, and when the check runs. See Insurance Eligibility Checks.

Note: Eligibility is provided by the clearinghouse integration. An RCM partner may offer its own eligibility on its platform, outside that integration.

Questions:

• What must you confirm: active coverage, covered service, in-network status, or benefit/cost detail?
• When does the check run: scheduling, check-in, or batch pre-visit?
• Do you re-check on a cadence for ongoing patients?
• Who works failed or ambiguous checks?

3.4 Prior Authorization & Estimates

Decide whether services need payer authorization before they happen, how you track that to a decision, and whether you produce patient cost estimates up front.

Note: the eligibility- and Claim-based rows below are one FHIR approach to prior auth; validate against your payer requirements. The standards-based CMS-0057-F path (CDS Hooks / CRD) is in alpha. Prior auth in a referral context is in the Referrals guide (3.7).

Questions:

• Do any services require prior authorization before scheduling or delivery?
• How do you check whether auth is required, and track a submitted auth to approval/denial?
• Must scheduling be gated until authorization clears?
• Do you owe patients a cost estimate before service (e.g. a Good-Faith Estimate)?

Good-Faith Estimates (No Surprises Act). One FHIR approach: build the estimate from pricing rules (ChargeItemDefinition/$apply, 3.5) and the patient’s cost-sharing (Coverage.costToBeneficiary, 3.1), delivered as a DocumentReference; validate against your compliance requirements. Mainly for self-pay and out-of-network patients.

Charge → Claim → Payer

Insurance-claims-specific. Self-pay builds skip to Patient & Operations; pricing (3.5) still applies to self-pay rates and estimates.

3.5 Charge Capture, Coding & Pricing

Decide what gets billed, where the codes come from, and how each line is priced. Coding is the largest source of denials, so treat it as first-class, not a byproduct of charge entry.

Questions:

• What generates a charge: a completed encounter, an order/procedure, a fulfilled service?
• Where do codes come from (CPT/HCPCS, ICD-10, modifiers): auto-derived, coder-reviewed, or manual (1.4)?
• Is pricing a single fee schedule, or does it vary by payer contract?
• Who reviews coding before a claim is built, and how do exceptions surface?

3.6 Claim Assembly & Submission

Decide how you build a valid claim from charges and coverage, and how it leaves your system. The 1.2 engine decision plays out here.

⚠ One-way door: Choosing a submission backend is hard to reverse. Each maps the Claim to a different format (837P, the partner’s API, a CMS-1500 PDF) with a different response pipeline (3.7), and payer identifier systems differ. Keep one Claim as the source of truth so the backend stays swappable.

Questions:

• Are you billing as an organization or an individual provider?
• Which submission path(s), and does it vary by payer (electronic for most, paper/portal for some)?
• What validation must pass before submission, and where do failures surface?
• Do you submit secondary claims after the primary pays (coordination of benefits)?

3.7 Payer Responses & Remittance Posting

Decide how you ingest what the payer sends back (the 277CA acknowledgment, accepted or rejected pre-adjudication, and the 835 ERA remittance, what was paid, adjusted, or denied line by line) and how payments post. These share one pipeline, so design them together.

Note: applies to the clearinghouse path, and the row specifics reflect the current integration. With an RCM partner, the partner owns response handling and posting; what flows back is its billing Tasks.

Questions:

• How do responses arrive: webhook push, polling, or partner API?
• How do you match a response to the originating claim?
• How do payer payments and adjustments post to the account?
• What share posts automatically vs. needs review?

3.8 Denials, Rejections & Resubmission

Decide how you work claims the payer rejects or denies: correcting and resubmitting, or appealing.

Note: The rows below are one FHIR approach to denial handling; validate against your workflow. On the clearinghouse path you build this in Medplum; with an RCM partner, denials are worked on the partner platform and surface back as synced Tasks.

Questions:

• Do you work front-end rejections (277CA) differently from adjudicated denials (835)?
• When you fix and resend, is it a corrected claim or a fresh submission?
• Do you track appeals (deadlines, supporting documentation, outcome)?
• How do staff find claims that need work?

Patient & Operations

3.9 Patient Responsibility & Self-Pay

Decide how you bill patients for their share (copays, coinsurance, deductibles, full self-pay) and how they pay.

Questions:

• What balances do you bill: post-adjudication responsibility, self-pay, or both?
• Do you issue statements, and on what cadence?
• Do you take online payment / card on file, through which processor?
• For out-of-network patients, do you provide a superbill instead of billing the payer?

3.10 Accounts Receivable, Aging & Lifecycle Status

Decide how you track where every claim and balance sits, and how staff find work that’s stuck or overdue.

Note: The rows below are one FHIR approach to AR tracking; validate against your reporting needs. Most relevant on the clearinghouse path; an RCM partner owns AR and reporting.

Questions:

• What lifecycle states matter (e.g. draft → submitted → accepted → paid → denied → closed)?
• How do you standardize states so queues, reports, and integrations agree?
• Do you track aging (days since submission, days pending) and AR buckets?
• How do staff find overdue or stuck claims and balances?

Value-Based

3.11 Value-Based & Capitation

Value-based care isn’t a claims pipeline; it splits into measurement (quality, gaps in care) and money (capitation, risk, settlement). Read only for capitated or risk-based contracts.

Note: Quality measurement uses documented operations; the financial rows are one FHIR approach to validate against your contracts. Quality/HEDIS reporting overlaps clinical analytics; see Analytics.

Questions:

• Which contracts are capitated or risk-based, and which members are attributed to you?
• Which quality measures (eCQM, HEDIS, stars) are you accountable for?
• Do you still submit claims or encounter data when capitated (for risk adjustment and measurement)?
• How are capitation payments and any shared-savings settlement reconciled?