EPIC SYSTEMS DATA MIGRATION

    Epic Systems Data Migration to Oracle Fusion — Clarity-First

    Pre-built Epic Systems data migration for downstream finance, HCM and SCM. Clarity-certified extractors, Cogito reconciliation, Chronicles never directly touched. FBDI/HDL emission, HIPAA-grade evidence, row-level reconciliation at every load.

    3-tier
    Reconciliation per load
    Clarity
    Native extraction layer
    HIPAA
    Chain of custody preserved
    Multi-TB
    Multi-hospital scale tested

    What epic systems data migration actually requires

    The hard part isn't pulling rows from Clarity. It's reconciling against Cogito, preserving HIPAA chain of custody, and emitting Fusion-grade FBDI/HDL without ever touching Chronicles.

    Epic Systems presents an unusual data architecture for migration. Chronicles, the InterSystems Caché/IRIS hierarchical MUMPS database, is the operational system of record — but it is never queried directly by external tools. Clarity, the SQL Server relational mirror, is the authorized read interface, refreshed from Chronicles on a configurable ETL schedule (typically 2 hours operational, 24 hours analytical). Cogito provides cubes and analytical models on top. Every epic systems data migration starts here: Clarity is the source, Cogito is the reconciliation reference, Chronicles is untouched.

    Oracle Fusion uses a different shape entirely. Finance data lands through FBDI (file-based data import) templates: Journal Import, AP Invoice Import, Supplier Import, Fixed Assets Import. HCM data lands through HDL (HCM Data Loader) .dat files: Worker, Element Entry, Salary. SCM lands through FBDI again: Item Import, Inventory Transaction Import, Cost Import. Each template has strict schema requirements that change between Fusion releases (currently 26x), and validation failures inside a Fusion ESS job are painful to diagnose.

    Every epic systems data migration to Oracle Fusion has to bridge those gaps without losing HIPAA chain of custody, without writing to Chronicles, without disrupting Clarity reporting users, and with reconciliation evidence that satisfies SOX, HIPAA, HITECH and Joint Commission auditors. Custom Python scripts and ad-hoc SQL can do it — but every domain becomes a multi-week negotiation between finance, HCM, supply chain, clinical informatics and compliance. Syntra ETL replaces that with pre-built crosswalks refined across dozens of healthcare conversions.

    Data domains covered out of the box

    1
    Resolute HB/PB AR feed
    Hospital and Professional Billing AR sub-ledger posting journals via Clarity ARPB_TRANSACTIONS — converted to FBDI Journal Import for Fusion GL.
    2
    GL history + balances
    Multi-year legacy GL history from Lawson/PeopleSoft/McKesson reconciled against Cogito, loaded to Fusion as opening balances + journal history via FBDI.
    3
    Worker + provider master
    CLARITY_EMP and CLARITY_SER employee/provider master converted to HDL Worker.dat for Fusion HCM Core HR, with provider-vs-employee role distinctions preserved.
    4
    Pharmacy + materials
    Willow, OpTime, Beaker inventory + transactions converted to FBDI Item Import and Inventory Transaction Import for Fusion Inventory + Cost Accounting.

    The Epic data conversion engine — six core capabilities

    The transformations Syntra ETL ships pre-built. No custom Clarity SQL, no bespoke conversion development, no Chronicles risk.

    🧮

    Resolute → COA mapping

    Resolute HB/PB journal posting rules walked, mapped to the new Fusion 7-segment healthcare COA (Entity/Service Area/Department/Account/Cost Center/Patient Type/Future). Full traceability per posting line.

    🔄

    Clarity → Cogito reconciliation

    Pre-built reconciliation harness compares Clarity extract counts/sums to Cogito reference counts/sums per period per service area. ETL lag detected and corrected before load.

    👥

    Worker vs provider classification

    CLARITY_EMP (employee) and CLARITY_SER (provider) intelligently merged where the same person plays both roles. Fusion Worker master populated correctly — no duplicate workers, no missing providers.

    📦

    Willow/OpTime/Beaker materials

    Pharmacy + surgical case-cart + lab reagent transactions converted to Fusion Inventory transactions with cost center context, expiration dates and lot tracking preserved.

    🏛️

    Fixed assets categorization

    Healthcare-specific asset categories (medical equipment, imaging, IT, furniture) mapped from legacy fixed-asset register to Fusion FA categories with full depreciation history.

    🔐

    HIPAA chain of custody

    Every read/transform/load step actor-logged, timestamp-logged, source-hash and target-hash recorded. 42 CFR Part 2 + HIPAA Privacy Rule compliant evidence pack.

    Epic systems data migration to Oracle Fusion — the load sequence

    A repeatable load order that respects Fusion's data dependencies. Skip a step and your AR feed fails on missing cost centers or workers.

    1

    Foundation (Setup) — Day 1

    Fusion enterprise structures, ledgers (typically per hospital legal entity), 7-segment healthcare COA, expense templates, departments, cost centers configured via FSM. Not user-facing data, but everything downstream depends on it.

    2

    Master Data — Days 2–6

    Workers (HDL Worker.dat from CLARITY_EMP + CLARITY_SER merge), supplier master (FBDI Supplier Import from legacy AP), item master (FBDI Item Import from Willow/OpTime/Beaker). Loaded in dependency order — workers before payroll, suppliers before invoices.

    3

    Opening Balances — Days 6–12

    GL opening trial balance per legal entity via FBDI Journal Import. AR opening (consolidated Resolute balance per service area) via FBDI Journal. AP opening, FA opening with full depreciation history. Reconciled to Cogito period-end snapshot.

    4

    Historical Detail — Days 10–20

    Multi-year journal history if needed for Fusion-side reporting; Resolute AR transaction history at summarised level; inventory transaction history. All hash-signed and reconciled at three tiers.

    5

    Steady-State Cutover — Days 18–28

    Resolute → Fusion GL posting feed cuts over to OIC integration. Willow/OpTime/Beaker → Fusion Inventory feeds activated via HL7 v2 / FHIR R4 through Interconnect. Legacy ERPs receive last journals, then move to read-only.

    6

    Parallel + Sign-off — Days 24–40

    1–2 month-end close cycles in parallel (legacy ERP + Fusion), Resolute downstream journals running into Fusion via the new feed, deltas captured and replayed. Sign-off pack issued to CFO, controller and internal audit. Production cut.

    What sets epic systems data migration apart from other ERP migrations

    The healthcare context changes everything — and Syntra ETL is built for it.

    🩺

    Clinical context awareness

    Migration team understands Resolute posting rules, Willow's pharmacy formulary structure, OpTime's preference cards, Beaker's lab order workflow. No clinical mistranslations into the Fusion COA.

    📅

    Year-end timing realism

    Healthcare year-end is typically June 30 or December 31 with cost-report deadlines that can't slip. Migration timing engineered around CMS cost report, state regulatory filings and 990 deadlines.

    🏥

    Multi-hospital instance pattern

    Common consolidation: 5–15 hospitals each on different legacy ERPs (Lawson, PeopleSoft, McKesson, regional installs) consolidating to one Fusion instance under one Epic clinical instance. Designed for this pattern.

    📞

    Foundation + grant accounting

    Foundation (501c3) entity often runs alongside the operating hospital. Grant accounting, restricted funds and donor reporting handled in Fusion Projects + GL with cross-entity views.

    🚑

    340B and supply chain context

    Pharmacy 340B program supply chain handled through Fusion Inventory with the right cost center and contract pricing context preserved from Willow. Critical for 340B audit.

    📋

    Joint Commission audit readiness

    All migration artefacts retained per Joint Commission and state retention (5–30+ years). Audit trail packaged for surveyors with one-click retrieval.

    Frequently asked questions

    What is Epic Systems data migration to Oracle Fusion?+

    Epic Systems data migration is the process of moving downstream finance, HCM and SCM data — never clinical — from Epic into Oracle Fusion. The technical heart: extract from Clarity (Epic's SQL Server relational mirror), reconcile against Cogito (analytics) and Chronicles (operational), then transform and load to Fusion via FBDI for finance/SCM and HDL for HCM. Scope includes Resolute HB/PB AR posting journals, GL history, Willow pharmacy inventory transactions, OpTime case-cart materials, Beaker lab reagents, supplier master, fixed assets and downstream worker master. Chronicles MUMPS database is never directly accessed — Clarity is the authorized read interface, preserving Epic's support model.

    How does Epic Systems data migration differ from EHR data migration?+

    Important distinction. EHR data migration means moving clinical records — patient charts, encounters, lab results, imaging, medications — from one EHR to another (e.g., Cerner to Epic). That is NOT what this is. Epic Systems data migration in the Oracle Fusion context means moving the downstream business data that has been feeding off Epic Resolute, Willow, OpTime and Beaker into the new Fusion ERP/HCM stack. Clinical records stay in Epic Chronicles, untouched. The Epic Systems data migration project is a finance/HCM/SCM project with Epic as the source of business data flows, not a clinical migration. This is a common misframing that adds months to consultant-led projects.

    What Epic tables does the data migration touch?+

    All extraction happens from Clarity (SQL Server). Common tables: ARPB_TRANSACTIONS and HSP_TRANSACTIONS (Resolute HB/PB AR), HSP_ACCOUNT (account aging), HSP_ACCT_TX_LIST (transaction list), CLARITY_EMP and CLARITY_SER (employee/provider master), CLARITY_DEP (department), CLARITY_FAC (facility), ZC_* code tables, plus Cogito-specific marts for summarised reporting. For inventory: CLARITY_ITM_MASTER, CLARITY_LOC. For Willow: RX_MED, RX_FILL. For OpTime: OR_LOG, OR_CASE. We never query Chronicles directly. Clarity ETL latency (typically 2–24 hours behind Chronicles) is factored into the Epic Systems data migration reconciliation strategy.

    How does Syntra ETL handle the Clarity ETL latency during migration?+

    Clarity is a SQL Server mirror that lags Chronicles by a configurable interval — usually 2 hours for operational reporting, 24 hours for some marts. During Epic Systems data migration we manage this with a Clarity freshness watermark check before each extract, reconciliation against Cogito (which also pulls from Chronicles), and where critical-path data needs sub-hour freshness, direct Cogito read or HL7 v2 message consumption. For finance data this rarely matters — Resolute posts journals on a daily batch anyway. For inventory and materials it sometimes matters — we coordinate the Willow/OpTime feed cutover with the Clarity refresh schedule so no transaction is dropped or double-counted between systems.

    Can Syntra ETL handle the volume of multi-hospital Epic data?+

    Yes. A typical 8-hospital regional system with 7 years of Resolute history produces ~50–80 million AR transaction rows, ~200 million GL journal lines, ~30 million inventory transactions in Willow/OpTime, and a few million worker/provider master records. Syntra ETL's Clarity extractors run in parallel across partitions (typically by service area + fiscal period), with extracts throttled to respect SQL Server CPU/IO limits on the Clarity environment (so reporting users are unaffected). Multi-TB extracts complete in 12–48 hours depending on infrastructure. Academic medical centres with 15+ hospitals and 10+ years of history typically run 4–7 days of total extraction time.

    What output formats does Syntra ETL produce for Fusion loading?+

    For finance: FBDI Journal Import (Resolute AR posting + legacy GL history), FBDI AP Invoice Import (supplier invoices), FBDI Supplier Import (vendor master), FBDI Fixed Assets Import. For HCM: HDL Worker.dat, HDL Element Entry.dat, HDL Salary.dat. For SCM: FBDI Item Import, FBDI Inventory Transaction Import, FBDI Cost Import. Plus REST API payloads for incremental delta loads during parallel run. Every payload is validated against the current Oracle Fusion 26x release schema before submission — errors surface locally during transform, not in a 4-hour Fusion ESS job that fails on row 47,000. Receipt-equivalent attachments (Resolute statements, supplier invoices) are bound via FBDI attachment metadata.

    How does row-level reconciliation work for Epic to Fusion loads?+

    Three reconciliation tiers per Epic Systems data migration load. Tier one: Clarity source row-count + sum vs Cogito-equivalent row-count + sum (catches Clarity ETL lag and partition gaps). Tier two: Fusion staging row-count + sum vs Clarity source post-transform (catches mapping errors). Tier three: Fusion posted row-count + sum vs Clarity at-the-instant snapshot (catches load failures). Every tier is hash-signed and timestamped. For each fiscal period, output is a reconciliation pack: Clarity vs Cogito vs Fusion to the cent, with full hash chain. Internal audit signs off on the pack; SOX and Joint Commission auditors retrieve it directly during their walkthroughs.

    Does Epic Systems data migration preserve HIPAA chain of custody?+

    Yes — that is the design constraint that drove the architecture. HIPAA, HITECH and 42 CFR Part 2 require demonstrable chain of custody for any PHI movement, with audit logs covering every read access for 6 years minimum and many states 7–30+ years. The Epic Systems data migration scope deliberately excludes PHI where possible (finance data is summarised at the GL-posting level, not patient-by-patient), and where PHI is unavoidable (worker provider master, certain billing-tied records) every read, transform and load step is logged with actor, timestamp, source row hash and target row hash. The audit pack is HIPAA-grade evidence. Your privacy officer and security officer sign off on the data-flow design before any extract runs.

    Plan your epic systems data migration with reconciliation built in

    Book a 30-minute discovery call. Walk through your Epic deployment, current legacy finance/HCM/SCM systems, Resolute configuration and reconciliation requirements. Concrete timeline and budget before the call ends — and Chronicles is never touched.