Epic Resolute Revenue Cycle: Billing, Charge Capture, and Claims Configuration Guide

Epic Resolute is the revenue cycle engine behind most Epic-running health systems, but implementations routinely go live with charge capture gaps, payer rule misconfigurations, and claim edit logic that drives denial rates up rather than down. This article covers what IT analysts, revenue cycle specialists, and build teams need to know to configure Resolute correctly – from charge capture and claim edit rules through payer plan setup, billing workflows, and post-go-live denial management.

What Is Epic Resolute?

Epic Resolute is the revenue cycle module within Epic Systems. It handles the financial side of patient care – charge capture, claim generation, payer submission, payment posting, denial management, and patient billing. Resolute comes in two distinct variants: Resolute Professional Billing for physician and outpatient claim processing, and Resolute Hospital Billing for inpatient and outpatient facility claims. Most integrated Epic health systems run both.

The core value of Resolute within Epic is integration. Charges flow directly from clinical documentation without manual re-entry. This eliminates the reconciliation gap that exists when clinical and billing systems are separate. But it also means clinical build decisions have direct revenue cycle consequences. A misconfigured order type, a missing charge trigger, or an incorrect billing visit type in Cadence creates a billing error that surfaces downstream in Resolute.

Revenue cycle implementation is consistently the most politically complex workstream in an Epic implementation. Clinical teams, IT build teams, finance leadership, compliance officers, and payer contract managers all have stakes in how Resolute is configured. The broader Epic module context is in the Epic EHR Learning Hub.

Charge Capture: How Epic Resolute Generates Charges

Charge capture in Resolute works through charge triggers – automated events that generate a charge record when a clinical action occurs. The three primary charge trigger mechanisms are order-based charging, documentation-based charging, and manual charge entry. Understanding which trigger applies to which service determines whether a charge is captured automatically or requires manual intervention.

Order-Based Charge Capture

Order-based charging fires a charge when a clinical order reaches a specified status – ordered, resulted, administered, or completed depending on the service type. A radiology order generates a technical component charge when the study is completed in the RIS. A laboratory order generates a charge when the result is verified. A medication order generates a pharmacy charge when the medication is dispensed from the ADC. Each trigger is configured in the order type and the charge event definition in Resolute.

The charge trigger status matters. Configuring a charge to fire at “ordered” rather than “resulted” means the health system charges for tests that were cancelled before completion. Build analysts must work with clinical operations to map each order type to the correct charge event status. Analysts who work with Epic EHR Orders and CPOE workflows already understand how order status flows – that knowledge applies directly here.

Documentation-Based Charge Capture

Documentation-based charging generates charges when a provider signs a clinical note or completes a specific documentation element. The E/M visit charge is the most common example. When a provider signs the visit note, Resolute’s charge router evaluates the visit type, documentation level, and payer to generate the appropriate E/M charge. Both the appointment type from Cadence and the provider’s documentation in Epic must be correct for the right charge to fire.

Procedure documentation charges fire when a provider documents a procedure in a specific encounter flowsheet or procedure note. If the clinical documentation template does not include the charge trigger configuration, the procedure is documented but not billed. Documentation quality directly impacts charge completeness – the EpicCare Inpatient ClinDoc guide is relevant revenue cycle reading even for billing analysts.

Charge Router and Charge Review Workflow

The charge router evaluates each charge trigger and determines how to process the charge: adding modifiers, splitting technical and professional components, routing to hospital or professional billing, or sending to a charge review queue. Charge review queues hold charges requiring a coder or billing specialist to verify before submission – charges needing modifier evaluation (modifier 25, 59, 26/TC), diagnosis specificity review, or specific payer documentation requirements.

Charge Description Master (CDM) Build and Governance

The Charge Description Master is the central catalog of every billable service, procedure, and supply. In Epic, the CDM is maintained in the charge (CHG) master file. Every charge trigger points to a CDM entry containing the CPT/HCPCS code, revenue code (for facility billing), charge amount, billing description, and department-specific attributes controlling how the charge routes through Resolute.

A hospital CDM can contain 10,000 to 50,000+ line items. Each must have correct CPT/HCPCS code assignment, correct revenue code, a charge amount reflecting the organization’s chargemaster price, and correct mapping to the clinical trigger. Annual CPT code updates (effective January 1) require CDM maintenance before go-live each year. Organizations that miss the annual update submit claims with deleted CPT codes – which payers reject outright.

CDM governance requires a defined owner and a change management process. In most health systems, CDM is jointly owned by revenue cycle and compliance, with clinical department input for new service lines. A CDM change request workflow – documenting who requested the change, clinical documentation supporting it, and who approved it – is not optional when OIG audit risk is considered. Build analysts configure the CDM in Epic but should not make unilateral CDM content decisions.

Claim Edit Rules and Scrubbing Logic in Epic Resolute

Claim edits validate a claim before it leaves Resolute and goes to the clearinghouse or payer. A claim that passes all edits submits cleanly. A failed claim routes to a work queue for correction. A well-configured claim edit environment catches rejectable or underpayable claims before submission, not after.

The National Correct Coding Initiative (NCCI) defines which CPT code pairs cannot be billed together without a supporting modifier. Resolute integrates CCI edit logic through third-party clinical editing software (Optum360, Cotiviti, or similar) or Epic’s native claim editing rules. CCI edits update quarterly – the build team must have a defined process for loading quarterly updates into Resolute’s edit engine and testing before they affect live claim submission.

Payer Plan Configuration and Contract Management in Resolute

Each payer has its own plan record in Resolute containing the payer’s claim submission preferences, expected reimbursement logic, coordination of benefits rules, and specific claim edit requirements. A payer plan built incorrectly means every claim submitted to that payer goes through a broken process.

The payer plan record contains the electronic claim submission path – the clearinghouse, trading partner ID, and electronic payer ID routing claims to the correct adjudication system. It contains the claim form type (837P or 837I), the billing provider NPI on the claim, the tax ID, the timely filing deadline, COB order, and prior authorization requirements by procedure category.

Expected reimbursement configuration requires loading contracted rates into Resolute. For Medicare, this means loading the Medicare Physician Fee Schedule rates by CPT code and locality. For commercial payers, this means loading the contracted fee schedule from the signed payer contract. Expected reimbursement lets Resolute flag underpayments when the 835 ERA posts – comparing expected versus actual payment and flagging variances above a configured threshold for AR follow-up.

COB misconfiguration creates duplicate billing risk. If a claim routes to the secondary payer without the primary payer’s EOB information, the secondary payer may deny it for missing COB data. Build analysts configure COB rules in the payer plan and test them with common multi-coverage patient profiles – Medicare plus supplement, commercial primary plus commercial secondary, Medicaid secondary.

Professional vs Institutional Billing in Epic Resolute

Hospital billing adds DRG complexity. Medicare inpatient reimbursement is based on the DRG – a classification of the patient’s diagnosis and procedure combination that determines a fixed payment rate. Resolute Hospital Billing incorporates a DRG grouper that assigns the DRG based on coded diagnoses and procedures. The principal diagnosis, secondary diagnoses, complications and comorbidities (CCs and MCCs), and procedure codes all affect which DRG is assigned. A coding error that misses a CC can cost the facility thousands in reimbursement on a single inpatient case.

HIPAA Transaction Sets in Epic Resolute

The 835 ERA payment posting workflow is where many Resolute implementations develop AR quality problems. When a CARC or RARC in the 835 is not mapped in Resolute, payment posts but the denial reason does not record – making denial analysis impossible. Build teams must map every CARC and RARC code used by each payer to Resolute’s denial reason catalog before go-live.

Denial Management and AR Workflows in Resolute

Denials are inevitable. The goal of Resolute’s denial management configuration is to make every denial visible, categorized, and workable as fast as possible. A denial sitting unworked for 45 days may be past the payer’s appeal deadline. Resolute routes denied claims to work queues based on denial reason, payer, and claim type. Build analysts configure the routing rules – which denial reasons go to coding queues, which go to authorization queues, which go to the front-end eligibility team.

Resolute’s reporting tools – Epic Reporting Workbench and SlicerDicer – allow revenue cycle leadership to analyze denial patterns by payer, denial reason, department, provider, and service type. This requires that denial reason codes are mapped consistently and reporting workbench reports are validated before go-live. Six Sigma process improvement methodology applies directly – a root cause analysis of high-volume denials identifies whether the root cause is upstream (registration errors, eligibility failures, missing authorizations) or downstream (coding errors, claim edit misses).

Testing and Validation Strategy for Epic Resolute

End-to-end billing cycle testing traces a test patient from registration through discharge, charge generation, claim creation, edit scrubbing, submission, payment posting, and denial handling. This requires Resolute connected to a test clearinghouse, payer sandbox environments, and test 835 ERA files simulating real payer responses. Organizations that test only charge generation and not the full claim submission and payment posting cycle regularly discover CARC/RARC mapping gaps and payment posting errors post-go-live.

Revenue cycle BAT requires billing staff and coders to complete real workflows in the test environment using realistic scenarios. Teams who have studied BAT vs UAT methodology understand that revenue cycle BAT is the functional acceptance gate – not just a QA sign-off on build configuration. A coder who cannot navigate the charge review queue in test is not ready for go-live.

Charge reconciliation testing compares charges generated by Resolute against clinical orders and documentation in test scenarios. Every clinical action that should generate a charge must be verified. A charge reconciliation audit report built in Epic’s Reporting Workbench – showing all orders placed in the test environment, the expected charge trigger, and whether the charge fired – should be run after each integrated testing cycle and reviewed by a revenue cycle analyst before sign-off.

Go-Live Planning and Common Revenue Cycle Failure Points

Revenue cycle go-live risk is financial. A 30-day AR spike caused by claim submission failures can create a cash flow crisis. Revenue cycle go-live planning must include cash flow modeling, AR baseline establishment, and a defined recovery plan if claims do not submit cleanly in the first 72 hours. The Epic EHR Go-Live Support framework covers command center structure – add a revenue cycle operations lead and a payer contract specialist to that model for Resolute go-lives.

Roles, Certifications, and Career Path for Resolute Specialists

Authoritative References

• CMS – ICD-10-CM/PCS Code Sets, Annual Updates, and NCCI Policy Manual
• CMS – Medicare Claims Processing Manual and Hospital Outpatient Prospective Payment System (APC)

Downloads: Resolute Revenue Cycle Templates and Checklists