MEDITECH DATA VALIDATION

    MEDITECH Data Validation — Post-Load Reconciliation to the Cent

    Row, sum, hash and business-rule reconciliation between MEDITECH MIS / HR/PR / Materials Management and Oracle Fusion Financials / HCM / SCM. Fund-accounting integrity preserved. NPR vs OTBI paired-report comparison. HIPAA-aware aggregated charge-feed reconciliation.

    4 surfaces
    Count · Sum · Hash · Business-rule
    Per-fund
    Operating · Restricted · Plant · Grant
    Paired
    NPR vs OTBI report comparison
    Signed
    Audit evidence per period per BU

    What meditech data validation has to prove — and how Syntra ETL proves it

    A bad meditech data validation looks like a clean cutover that breaks under the first external audit. The Syntra ETL validation engine exists to make sure the data in Fusion matches MEDITECH at every level finance, HR, supply chain, internal audit, external audit, HIPAA reviewers and the privacy officer care about.

    Hospital finance teams answer to multiple audit constituencies simultaneously. External auditors test trial balance integrity to the cent. CMS RAC reviewers test billing, charge and claims evidence accuracy for the audit window. Joint Commission reviewers test patient-care-relevant data integrity. State hospital association reviewers test retention compliance. Internal audit tests SOX-grade financial controls. HIPAA reviewers test minimum-necessary and BAA-governed access. The meditech data validation has to satisfy all of them, simultaneously, with a single audit-evidence pack.

    The hard problem is that MEDITECH and Oracle Fusion calculate some metrics differently. NPR Report Writer routinely embeds business logic (cost-center rollups, payer-mix derivations, contractual-adjustment calculations) that has to be reproduced exactly in Fusion OTBI / BI Publisher — otherwise the validation finds variances that are really methodology differences, not data corruption. The Syntra ETL meditech data validation engine pairs MEDITECH NPR output against Fusion OTBI output report-by-report for the critical reports, so variances are diagnosed at the methodology layer, not at the data layer.

    The output is a per-period per-BU signed audit pack covering trial balance per fund, AP balance and voucher count, HCM employee and payroll YTD, materials value and transaction count, charge-feed aggregated reconciliation, and paired NPR vs OTBI report comparison. Every audit constituency consumes the same pack.

    Reconciliation surfaces the validation engine covers

    1
    Trial balance per fund
    Operating, restricted, plant, grant funds reconciled MEDITECH MIS vs Fusion GL per period per BU, to the cent.
    2
    AP & supplier
    Voucher count, supplier count, total AP balance MEDITECH vs Fusion, with per-supplier variance diagnostics.
    3
    HCM & payroll
    Employee count, payroll YTD balance per employee, deduction totals MEDITECH HR/PR vs Fusion HCM, with effective-date integrity check.
    4
    Materials & SCM
    Item count, on-hand value per locator, transaction totals MEDITECH Materials Management vs Fusion SCM.

    The six dimensions of meditech data validation

    Reconciliation surfaces and the audit evidence the engine produces for each.

    📒

    Fund-accounting trial balance

    Per-fund trial balance reconciliation — operating, restricted, plant, grant — to the cent per period per BU.

    💰

    AP voucher & supplier

    Voucher count, supplier count, AP balance reconciled with per-supplier variance diagnostics.

    👥

    HCM employee & payroll YTD

    Employee count, payroll YTD per employee, deduction totals reconciled with effective-date integrity.

    📦

    Materials on-hand & transactions

    Item count, on-hand value per locator, transaction totals reconciled MEDITECH vs Fusion.

    🩺

    Charge feed aggregated

    Daily cost-center-day-payer net revenue reconciled MEDITECH B/AR vs Fusion GL via FBDI feed. PHI never in evidence.

    📊

    NPR vs OTBI paired reports

    Critical NPR reports vs OTBI / BI Publisher equivalents — line-by-line comparison for the controller's monthly close pack.

    How meditech data validation runs through the migration

    Validation is not a one-time post-load activity — it runs continuously through extract, transform, load and parallel-run.

    1

    Extract-Time Hashing — Every Extract

    Every record hashed at MEDITECH extract — SHA-256 per record, manifest signed per extract. Establishes chain-of-custody from source.

    2

    Transform-Time Validation — Every Transform

    Crosswalk applied with validation rules per field — data type, length, allowed values, referential integrity, business rules. Failures captured pre-load.

    3

    Load-Time Reconciliation — Every Load

    Post-FBDI / HDL load: count, sum and hash comparison MEDITECH vs Fusion per business unit per period per domain. Variance diagnostics surfaced.

    4

    Daily Parallel-Run Reconciliation — Cutover Window

    Scheduled daily reconciliation pack during 1–2 fiscal month parallel-run: MEDITECH delta extract vs Fusion delta load, variances routed to accountable party.

    5

    NPR vs OTBI Paired Report Run — Cutover Window

    Critical NPR Report Writer reports vs OTBI / BI Publisher equivalents run for the same period and scope, output compared line by line.

    6

    Cutover Sign-Off Pack — Cutover Day

    Final per-period per-BU signed audit pack covering all reconciliation surfaces. Signed by controller, AP manager, HR director, materials manager and privacy officer.

    Audit evidence the meditech data validation engine produces

    One pack, multiple audit constituencies.

    📋

    Trial balance per fund

    MEDITECH MIS vs Fusion GL per fund per period per BU, to the cent. Signed by controller.

    💰

    AP & supplier reconciliation

    Voucher count, supplier count, AP balance with per-supplier diagnostics. Signed by AP manager.

    👥

    HCM & payroll reconciliation

    Employee count, payroll YTD, deduction totals with effective-date integrity. Signed by HR director.

    📦

    Materials & SCM reconciliation

    Item count, on-hand value, transaction totals. Signed by materials manager.

    🩺

    Charge feed aggregated reconciliation

    Daily net revenue per cost-center per payer. Signed by privacy officer (HIPAA-aware).

    📊

    NPR vs OTBI paired comparison

    Critical NPR vs OTBI / BI Publisher line-by-line output. Signed by controller for the monthly close pack.

    Frequently asked questions

    What does meditech data validation cover after a Fusion load?+

    Meditech data validation is the post-load reconciliation discipline that confirms data extracted from MEDITECH and loaded into Oracle Fusion matches at the count, sum, hash and business-rule level. It covers four reconciliation surfaces. (1) Count reconciliation: number of GL journals, AP vouchers, suppliers, employees, items, materials transactions per fiscal period per business unit, MEDITECH source vs Fusion destination, identical to the row. (2) Sum reconciliation: total debits, credits, AP balance, AR summary, payroll YTD, materials value per period per BU, identical to the cent. (3) Hash reconciliation: per-record SHA-256 hash at extract vs re-hash post-load, confirming no data tampering or corruption between source and destination. (4) Business-rule reconciliation: service-line P&L, cost-center variance, payer-mix and fund-accounting balances reconcile MEDITECH NPR / DR reports vs Fusion OTBI / BI Publisher reports for identical numbers.

    How does meditech data validation handle MEDITECH's fund-accounting structure?+

    Fund-accounting reconciliation is the single most-scrutinized part of any hospital meditech data validation. MEDITECH MIS module carries operating, restricted, plant and grant funds as either a chart segment or a balancing dimension; Fusion preserves the same fund integrity through a dedicated COA segment or balancing-segment logic. The meditech data validation engine runs trial-balance reconciliation per fund per period: MEDITECH operating-fund trial balance vs Fusion operating-fund trial balance, MEDITECH restricted-fund trial balance vs Fusion restricted-fund trial balance, MEDITECH plant-fund vs Fusion plant-fund, MEDITECH grant-fund vs Fusion grant-fund. Any variance is reported at the cost-center-account level, ready for diagnosis. Hospital finance controllers — and external auditors at year-end — depend on fund-level reconciliation matching to the cent.

    What reconciliation tolerance is appropriate for meditech data validation?+

    Three tolerance tiers, by data domain. Tier 1 — zero tolerance: GL trial balance per fund per period, AP voucher count and balance, supplier count, employee count, payroll YTD balances. These reconcile to the cent and to the row, no exceptions. Tier 2 — accounting tolerance (defined per project but typically $0.01 per period per BU): cumulative rounding effects from rate-based or percent-based derivations that propagate through summary postings. Tier 3 — business-rule tolerance: derived analytical metrics (service-line P&L, cost-per-case, payer-mix margins) where MEDITECH and Fusion calculate using slightly different methodologies and the variance is documented and reviewed but not blocking. Syntra ETL's meditech data validation engine reports against all three tiers per period per BU per domain — and finance sign-off requires explicit acceptance of Tier 2 and Tier 3 variances.

    How does meditech data validation handle the NPR Report Writer parallel-run?+

    The cleanest evidence that the meditech data validation has succeeded is identical business reports produced from both MEDITECH NPR and Fusion OTBI / BI Publisher during the parallel-run period. The validation engine drives a paired NPR vs OTBI report-run schedule for the critical 40% of NPR reports that survive into Fusion: NPR runs against the closing MEDITECH MIS module, OTBI runs against the loaded Fusion data, both for the same period and same scope, output compared line by line. The 'are the controller's monthly close reports identical?' question becomes a literal binary check rather than a judgment call. Any variance is investigated against the mapping document — typically traced to an NPR business-logic capture gap that gets fixed in the canonical model and rerun.

    Can meditech data validation handle MEDITECH MAGIC and Expanse environments together?+

    Yes. Multi-platform IDNs running MAGIC at acquired entities and Expanse at the consolidating entity face the same validation challenge: all extracted data converges to one Fusion ledger, but the validation evidence has to attribute back to the source environment per entity. The Syntra ETL meditech data validation engine tags every record with source platform (MAGIC / C/S / 6.x / Expanse) and source entity at extract, preserves the tag through transformation and load, and produces per-entity reconciliation reports against the unified Fusion ledger. If MAGIC entity A has a variance and Expanse entity B reconciles cleanly, the diagnostics point at the MAGIC entity A's specific NPR extract or DR query, not at the consolidated Fusion ledger as a whole. Multi-platform reconciliation is no harder than single-platform reconciliation, just more reports.

    How does meditech data validation handle HIPAA-aware patient billing summary reconciliation?+

    The patient billing summary feed (daily charge journal from MEDITECH B/AR module to Fusion GL) is the most sensitive validation surface because PHI must never appear in any reconciliation report. Validation runs at the aggregated grain only: cost-center-day-payer net revenue, contractual adjustments, write-offs, charity care — never patient-level detail. MEDITECH's NPR-driven daily charge journal totals are compared to Fusion FBDI Journal Import totals per cost-center per payer per day. Any variance is investigated at the aggregated grain; if patient-level diagnosis is required to resolve a variance, that work happens inside the MEDITECH HIPAA boundary with privacy-officer oversight and limited-data-set protocols, and the resolution lands as an aggregated correction in Fusion. PHI never enters the validation evidence pack.

    What audit evidence does meditech data validation produce?+

    Six artifacts per period per BU. (1) Trial balance reconciliation per fund — MEDITECH MIS vs Fusion GL, to the cent. (2) AP reconciliation — voucher count, supplier count, total AP balance, MEDITECH vs Fusion. (3) HCM reconciliation — employee count, payroll YTD balance per employee, deduction totals, MEDITECH HR/PR vs Fusion HCM. (4) Materials reconciliation — item count, on-hand value per locator, transaction totals, MEDITECH Materials Management vs Fusion SCM. (5) Charge feed reconciliation — daily net revenue per cost-center per payer, MEDITECH B/AR vs Fusion GL via FBDI feed. (6) NPR vs OTBI paired-report comparison for the critical 40% of NPRs. All six artifacts are signed, timestamped and packaged for internal audit, external audit, HIPAA / Joint Commission / CMS RAC review and the privacy officer.

    Can meditech data validation be automated for ongoing parallel-run periods?+

    Yes — and automation is essential for a 1–2 fiscal month parallel-run window. The Syntra ETL meditech data validation engine runs as a scheduled comparison job: daily delta reconciliation between MEDITECH MIS, HR/PR and Materials Management modules and the Fusion staging / production ledger. Each run produces an updated reconciliation pack with variance flags routed to the appropriate accountable party (controller for GL variances, AP manager for voucher variances, HR director for HCM variances, materials manager for SCM variances, privacy officer for charge-feed variances). The full daily reconciliation pack runs in under two hours regardless of period size. Cutover sign-off becomes a structured review of a clean reconciliation pack, not a frantic month-end variance hunt.

    Get reconciliation-grade meditech data validation

    Book a 30-minute discovery call. We'll walk through your fund-accounting structure, NPR Report Writer library, parallel-run window and audit constituencies — and show how the Syntra ETL meditech data validation engine produces signed audit evidence at every load.