Revenue is where an Epic integration gets unforgiving. A reporting feed can be a day late, and nobody panics. A claims feed that drops 837 files, or a payment-posting process that misapplies an 835, costs the hospital real money and real staff time. Epic Resolute is the module at the center of that, and any vendor working near the revenue cycle has to understand how it moves money.
This guide explains Epic Resolute for the people who scope and build revenue-cycle integrations: what Resolute is, how Hospital Billing and Professional Billing differ, how claims and remittance actually flow, and where third-party systems connect. For the full module-by-module view, our Epic integration services is the hub this guide links back to.
What is Epic Resolute?
Resolute is Epic's revenue-cycle module. It takes the charges generated during care, turns them into claims, sends those claims to payers, and posts the payments that come back. It splits into Hospital Billing for facility charges, Professional Billing for clinician charges, and a Single Billing Office model that unifies the two for the patient. If money moves through Epic, it moves through Resolute.
The reason Resolute matters to integrators is that the revenue cycle is rarely self-contained. Claims go out to clearinghouses and payers, remittances come back, eligibility is checked against external services, and analytics tools pull billing data for reporting. Each of those is an integration point with its own format and failure modes.
Hospital Billing, Professional Billing, and SBO
The HB/PB distinction confuses people outside the revenue cycle, so it is worth getting right.
Hospital Billing (HB) handles institutional charges, the facility side, and produces 837I claims on the UB-04 standard.
Professional Billing (PB) handles the clinician's professional charges and produces 837P claims on the CMS-1500 standard.
Single Billing Office (SBO) combines HB and PB so the patient receives one statement instead of two, which is simpler for patients and increasingly common. Which of these a hospital runs shapes the claim formats and workflows your integration has to support.
How claims and remittance flow
Every Resolute integration handles two opposite flows, and keeping them straight is half the battle.
On the way out, Resolute generates 837 claim files, 837P for professional and 837I for institutional, and sends them to a clearinghouse such as Waystar, Availity, Change Healthcare, or Trizetto, which forwards them to the payer. On the way back, the payer returns an 835 Electronic Remittance Advice that carries payment and adjudication details. Resolute's posting rules auto-post those payments, matching them to the right charge lines by payer ID, procedure code, and contract rates, applying contractual adjustments along the way.
Denials live inside that 835. When a payer denies or reduces a line, the reason arrives as CARC and RARC codes, and well-configured Resolute routes those to denial work queues so staff can act on them. A revenue-cycle integration that ignores denials leaves money on the table.
Where Resolute integrations connect
Most revenue-cycle work clusters around three connection points.
Clearinghouse integration covers 837 claim submissions and 277 status checks, usually through one of the major clearinghouses. Payment posting automates cash by auto-posting 835 ERAs, applying contractual adjustments, and matching payments to charges so staff are not keying remittances by hand. Denials and analytics use the CARC/RARC data to route denials to work queues and to feed revenue dashboards that show where money is stuck. If you are building near any of these, the data contracts and edge cases are where projects live or die.
The gotchas that cost revenue
The revenue cycle punishes small mistakes, so these deserve attention:
- Claim format precision. 837P and 837I have strict requirements, and payers add their own edits. A malformed claim is a rejected claim and a delayed payment.
- Posting rule accuracy. Auto-posting logic that misapplies payments or adjustments creates reconciliation work that wipes out the time it was meant to save.
- Denial handling. Denials buried in 835 files that never reach a work queue are lost revenue. Routing them correctly is essential.
- Clearinghouse specifics. Each clearinghouse has its own connection and quirks. "We support 837" is not the same as "we are live with your clearinghouse."
- PHI and financial data security. Revenue data is both PHI and financially sensitive, so access control and audit logging are mandatory.
Resolute, reporting, and your stack
Revenue-cycle analytics usually reads billing data out of Clarity or Caboodle rather than querying Resolute directly, the same pattern as any other Epic reporting; our Epic Clarity guide and Epic Caboodle guide cover those layers. For real-time financial transactions, Epic also exposes targeted web services; our guide to third-party Epic integration maps those methods.
Inside an 837 claim
It helps to see what a claim integration is really moving. An 837 is an X12 EDI file, a set of segments and loops rather than human-friendly text. A small slice of an 837P carries the billing provider, the subscriber, the claim, and the service lines:
NM1*85*2*FAMILY CLINIC*****XX*1234567893~
SBR*P*18*******MC~
CLM*PATACCT123*250***11:B:1*Y*A*Y*Y~
LX*1~
SV1*HC:99213*125*UN*1***1~
DTP*472*D8*20260518~Every segment has a job: NM1 identifies a party, CLM carries the claim, SV1 a professional service line with its procedure code and charge. Payers layer their own edits on top of the X12 rules, so a file that passes a generic validator can still be rejected by a specific payer. This is why "we support 837" and "we are live and paid through your clearinghouse and payers" are very different statements.
Why denials deserve their own workflow
Denials are where revenue quietly leaks. When a payer reduces or rejects a line, the reason rides back inside the 835 as CARC and RARC codes. Well-run Resolute setups translate those codes into routed work queues so staff can correct and resubmit, and they feed the same data into dashboards that show denial rate by payer, by reason, and by service line. An integration that posts payments but ignores denials looks like it is working while steadily losing money. Treating denial routing as a first-class part of the build, not an afterthought, is what protects the bottom line.
Charge capture is where it starts
Clean claims depend on clean charges. Resolute relies on accurate charge capture upstream, from charge routers and the clinical documentation that drives coding. When an integration touches charge capture, for example, pushing charges from an external system into Epic, the precision required is high: a missed or miscoded charge becomes a denied claim weeks later. Scoping a Resolute project well means looking at the whole path from the charge to the posted payment, not just the claim file in the middle.
How we approach Epic Resolute work
Healthcare is the only industry we work in, and we have built EHR and revenue-cycle integrations for 30+ healthtech startups and hospital teams. We have worked with 837 claim generation, 835 posting logic, clearinghouse connectivity, and denial routing, so the formats and failure modes above are familiar rather than new.
Our work is HIPAA-compliant by default, with SOC 2 and ISO 27001 behind it, which matters when both PHI and financial data are in scope. The pattern we see is that revenue-cycle integrations succeed when claim formats, posting rules, and denial handling are designed together, because a gap in any one of them shows up as lost or delayed cash.
Eligibility, prior authorization, and the front end
Clean revenue starts before the claim. A large share of denials trace back to eligibility and prior-authorization problems at registration, not to billing errors later. Resolute integrations often extend to real-time eligibility (270/271) checks and prior-authorization workflows, so coverage is verified while the patient is still in front of you rather than weeks later when a claim bounces. Building these front-end checks into the flow reduces the denial volume the back end has to work.
This is also where Epic's web services come in. Real-time financial transactions such as eligibility do not fit the nightly reporting model or the batch 837/835 exchange; they need a synchronous call, which Epic exposes through targeted web services. A complete revenue-cycle integration usually spans both: synchronous checks at the front end and batch claims and remittance at the back.
The pattern that works is to map the whole revenue cycle once, from registration and eligibility through charge capture, claim submission, remittance, and denials, and then decide which steps you are integrating and which you are leaving to Epic. Revenue leaks at the seams between these steps, so naming the seams explicitly is the most useful thing a scoping exercise can do, because each seam is a place where a charge, a claim, or a payment can fall through and quietly become lost revenue.
Where to start
List the revenue-cycle touchpoints you actually need: which claim types, which clearinghouse, whether you are posting 835s, and whether denials route into a queue. That scope decides the formats and integration points your project has to cover.
If you want help scoping or building a Resolute integration, see our Epic integration services, or reach out to talk through your revenue-cycle workflows.
