Domain-object deep dive: which Epic data actually moves to Oracle Fusion (downstream finance, HCM, SCM) and which stays in Chronicles (all clinical). Encounters, patient records, MyChart, clinical history — stay in Epic. Downstream Resolute/Willow/OpTime/Beaker feeds connect via OIC + Interconnect.
The most important sentence in any Epic-to-Fusion discovery is also the simplest: Epic stays as the clinical system of record; Fusion is the back-office finance/HCM/SCM. Patient records do not migrate.
Epic Chronicles holds the clinical record — the system of truth for patient encounters, problems, allergies, medications, vitals, lab results, imaging interpretations, surgical notes, ED visits, inpatient admissions, ambulatory visits, MyChart patient portal interactions. EpicCare Inpatient and EpicCare Ambulatory are the clinician-facing workflows. Hyperspace (legacy thick client) and Hyperdrive (newer web-based UI) are the desktop applications. None of that moves to Oracle Fusion in a finance/HCM/SCM migration. Chronicles MUMPS data is never queried by Syntra ETL.
What does move to Oracle Fusion is the downstream business data generated as a byproduct of those clinical encounters. Every patient encounter in EpicCare generates downstream feeds: Resolute HB/PB picks up the charge capture and produces AR sub-ledger posting; Willow records the medication dispensed and generates pharmacy inventory consumption; OpTime records the surgical case materials and generates supply chain consumption; Beaker records the lab reagent used and generates lab inventory consumption. Those downstream feeds — and only those — move to Oracle Fusion via integration. Patient identifiers ride along only where required for cost allocation, with HIPAA minimum-necessary scoping.
This framing matters because consultants — especially Big Four firms — sometimes pitch "Epic to Oracle migration" as if it includes the clinical record. It does not. Epic is the #1 US EHR with ~30%+ of US hospital beds; you do not migrate Epic clinical to another EHR unless you are explicitly switching EHR vendors (which is a multi-year, $50M–$500M project belonging to clinical leadership, not back-office finance). Epic-to-Fusion in the Syntra ETL context is back-office consolidation: legacy ERPs (Lawson, PeopleSoft, McKesson, on-prem EBS) replaced by Fusion. Epic continues. Patients see no change.
A clear table of clinical-vs-downstream for every major Epic domain object. Buyers and project teams use this to scope correctly from week one.
Stay in Chronicles. EpicCare documentation, problem lists, allergies, MyChart portal — all unchanged. Patient-level demographic data NOT replicated to Fusion.
Encounter records stay in Chronicles. Downstream Resolute charge capture from the encounter posts to Fusion GL as summarised AR sub-ledger journal (not patient-level).
Resolute HB/PB billing history stays in Resolute as patient-billing system of record. Fusion GL receives consolidated AR balance per period × service area — not patient detail.
Chronicles holds clinical history (results, vitals, notes, imaging interpretations). Cogito provides authorized analytics access to finance for cost-allocation cuts.
Lab results (Beaker LAB_RSLT) stay in Chronicles for clinical use. Reagent consumption downstream from order completion feeds Fusion Inventory — not the result.
Patient medication history stays in Chronicles. Willow inventory consumption (item × location × period) feeds Fusion Inventory. 340B flag preserved at item-transaction level.
An anatomy of one outpatient encounter — what Epic captures, what Fusion sees. Patient context preserved or stripped per HIPAA minimum-necessary.
Patient arrives. Prelude registration in Epic captures demographic/insurance. ADT message emits via Interconnect. Encounter ID created. EpicCare opens encounter for clinical documentation.
Clinician documents in EpicCare, orders labs via Beaker (ORDER_PROC), prescribes meds via Willow (RX_MED). Imaging interpreted in Radiant. ED workflow tracked in ASAP. All clinical data lands in Chronicles.
Resolute HB or PB captures chargeable services from encounter. Charge transactions land in ARPB_TRANSACTIONS or HSP_TRANSACTIONS. Patient-level AR aging updates in Resolute.
Resolute generates downstream AR posting journal — period × service area × account summarised. Posting emits via Interconnect to OIC. NO patient identifier in summarised posting — minimum-necessary.
OIC transforms to FBDI Journal Import format, posts to Fusion GL. Three-tier reconciliation runs. Encounter's contribution to AR is now in Fusion GL as part of the day's consolidated posting.
Every step audit-logged: actor, timestamp, source hash, target hash. HIPAA §164.312(b) chain of custody preserved. Encounter clinical record remains intact in Chronicles.
The questions Big-Four sales decks don't answer clearly. Read these before signing any Epic-to-Fusion SOW.
No. MyChart is unchanged. EpicCare clinical documentation is unchanged. Patient experience is identical — Fusion runs the back office, not the chart.
Not for the bulk migration scope — that's Clarity-driven extraction. You DO need HL7/FHIR expertise for the steady-state Willow/OpTime/Beaker feeds — but that work is integration build, not data migration.
No. Patients continue receiving Resolute-generated statements through MyChart. Fusion sees the consolidated AR balance; patient-level billing stays in Resolute.
Not for the Epic-to-Fusion migration scope. Clinicians' EpicCare workflows are unchanged. Back-office staff (AP, GL, FP&A) get Fusion training. Revenue cycle staff continue in Resolute.
Preserved by design. Minimum-necessary PHI scoping at every downstream feed. Audit logs at every hop. HIPAA §164.312(b), 42 CFR Part 2 — all satisfied by default.
Different project. Epic-to-Cerner or vendor-EHR-to-Epic conversions are clinical migrations, $50M–$500M, multi-year. Syntra ETL is NOT that tool. Discovery call separates.
No — and this is the most important clarification on this page. Patient records, encounters, clinical history, lab results, imaging, medications, allergies, problem lists, vitals — all the clinical data — stay in Epic Chronicles as the system of record. Oracle Fusion is finance/HCM/SCM, not a clinical system. What this page covers is the downstream business data feeding off these clinical events: the billing transactions generated by Resolute HB/PB from encounters; the pharmacy consumption recorded by Willow from medication dispenses; the surgical materials recorded by OpTime from operative encounters; the lab reagent consumption recorded by Beaker from order completion. Those downstream feeds move to Oracle Fusion via the integration architecture. The clinical record stays untouched.
Because the SEO query "epic systems patient records encounters billing clinical history migration" is genuinely searched — but searchers are usually one of three audiences: (a) IT leaders who haven't yet realized that Epic-to-Fusion is a finance/HCM/SCM project not a clinical project; (b) finance/HR teams who hear the phrase and need to understand what does move; (c) Big Four consultants who promise a clinical migration that nobody should actually attempt. This page exists to provide the clear, correct framing — Epic stays as the clinical EHR; the back-office stack moves to Oracle Fusion; downstream feeds connect the two through OIC + Interconnect. The Syntra ETL platform is built around this correct framing, not the misframing.
Every clinical encounter in Epic generates downstream business data. The patient encounter itself stays in Chronicles (EpicCare documentation, vitals, problem lists, orders, results). The downstream feeds are: Resolute HB/PB charge capture from the encounter (chargeable services, supplies used, medications administered) → Fusion GL as AR sub-ledger posting; Willow medication consumption from the encounter → Fusion Inventory; OpTime materials consumption from surgical encounters → Fusion Materials; Beaker lab reagent consumption from order completion → Fusion Inventory. The encounter ID and patient context travel with the downstream feed where required for cost-allocation and reconciliation — but always with HIPAA minimum-necessary scoping and PHI protections.
Resolute HB/PB billing history stays in Resolute as the system of record for patient and payer billing. AR aging stays in Resolute. Statement history stays in Resolute. Claim history (837/835) stays in Resolute. Contractual adjustment history stays in Resolute. What moves to Fusion GL is the summarised AR sub-ledger posting per period per service area — the consolidated balance the CFO needs for trial balance, not the patient-level detail. This preserves Resolute as the patient-billing system of record (where billers, patient financial counsellors and revenue cycle staff continue to work) while giving Fusion the consolidated balance needed for GL close. Drill-down from Fusion GL line to Resolute detail happens via Cogito link, preserving the chain of custody.
Minimum-necessary scoping at every step. Resolute downstream journal posting is summarised at the period × service area × account level — not patient-level. Worker master in HDL contains employee/provider attributes — DEA, NPI, specialty — but not patient data. Willow inventory consumption is item-level not patient-level. OpTime materials are case-cart not patient-record. Beaker reagent consumption is order-completion level not result-level. Where patient context is required for cost allocation (some 340B contract pricing scenarios), the encounter ID and patient class ride along but the clinical detail does not. HIPAA Privacy Rule and 42 CFR Part 2 (substance use disorder) compliance is reviewed by the privacy officer before any feed activates.
Finance teams sometimes need clinical context for cost allocation, contract pricing, denial root-cause and grant accounting. After cutover the workflow is: finance staff working in Fusion drill from a GL line through to Resolute for AR detail, and from Resolute to Cogito for clinical context (encounter type, service line, payer mix, contractual relationship). Cogito is the analytics gateway — finance staff are granted scope-limited Cogito access for the cuts they need. Direct Chronicles access remains restricted. The drill chain is Fusion GL → Resolute AR → Cogito clinical context, with HIPAA actor logs at every access. Patient-identifiable clinical history is never duplicated into Fusion.
No. MyChart (Epic's patient portal) is a clinical-facing application reading from Chronicles. Patients continue to log in, see their records, message providers, schedule appointments, request prescription refills, pay bills (through Resolute's patient billing) — unchanged. The Fusion-side migration is invisible to MyChart users. The only MyChart-adjacent change post-cutover is that patient refunds initiated in Fusion AP (when applicable) eventually appear on the MyChart statement — but that's the same flow patients see today, just with Fusion as the back-office payment engine instead of the legacy ERP. MyChart's clinical functionality is fully preserved.
When IT or procurement leadership searches "epic systems patient records encounters billing clinical history migration" they're often evaluating an EHR-to-EHR conversion (Epic-to-Cerner, Cerner-to-Epic, MEDITECH-to-Epic). That is a different project entirely from Epic-to-Oracle-Fusion. Epic-to-Oracle-Fusion is back-office consolidation: Epic stays clinical, Fusion replaces legacy ERPs. If your project intent is genuinely EHR-to-EHR (i.e., moving clinical records between two EHR vendors), Syntra ETL is not the right tool — that work belongs with Epic's TogetherCare or specialist clinical-migration vendors. If your project intent is back-office consolidation while leaving Epic in place, Syntra ETL is the purpose-built platform. The discovery call separates the two.
Book a 30-minute scoping call. We'll clearly separate clinical (stays in Epic) from downstream (moves to Fusion), walk through your Resolute HB/PB downstream feed, your Willow/OpTime/Beaker integration design and your HIPAA framing. Clear scope before the call ends.