Allscripts / Veradigm Data Validation — Four Families, Per-Facility Sign-Off

Allscripts / veradigm data validation runs four families of verification against every post-load state. Family one: row counts — number of encounters extracted from Sunrise / TouchWorks / Practice Fusion equals number of journal lines in Fusion GL per facility per fiscal period; number of supply consumption lines in Allscripts equals number of inventory transactions in Fusion SCM; number of clinician provider records equals number of HCM Workers. Family two: sum totals — gross charges from Allscripts charge_dtl equals gross revenue in Fusion GL to the cent per period; contractual adjustments in Allscripts equals Fusion contra-revenue per payer per period; supply spend in Allscripts equals SCM consumption value per item category. Family three: hash signatures — SHA-256 per record extracted and per record loaded reconciles bit-for-bit. Family four: cross-source consistency — Sunrise vs TouchWorks vs Practice Fusion vs dbMotion for the same encounter window reconcile against each other before crossing to Fusion.

The validation engine treats Sunrise (or Altera Sunrise) and Veradigm ambulatory as separate reconciliation domains that converge at the Fusion landing zone. For health systems running both — Sunrise for acute and TouchWorks / Practice Fusion for ambulatory — the validation reconciles each source against its own Fusion-side subset (Sunrise charges to Fusion ledger A or to a specific Fusion business unit; TouchWorks charges to Fusion ledger B or BU). For multi-facility IDNs, validation runs per facility per fiscal period — a Sunrise hospital's monthly close reconciles to its Fusion BU close while ambulatory practices reconcile to their own Fusion BU close. Cross-source consistency checks (dbMotion's unified patient identity reconciled against Sunrise and TouchWorks separately) catch any patient-identity drift caused by the 2022 split. Validation results are facility-scoped and BU-scoped so the CFO can sign off on each independently.

Yes. PHI never appears in the validation engine itself — only counts, sums, hashes and pseudonymized tokens. Where patient-level reconciliation is needed (e.g. validating that a specific encounter in Sunrise matches a specific charge in Fusion), the comparison runs on the KMS-pseudonymized token rather than the source MRN. Where PHI inspection is required for an audit, the validation engine logs the patient pseudonym, user, timestamp, scope, purpose and recipient — and the analyst with appropriate authorization de-pseudonymizes within a separate KMS-controlled audit interface. The validation engine itself crosses the BAA boundary as a count/sum/hash service only, with full HIPAA accounting-of-disclosures logging for any deeper inspection.

Sunrise's pt_encounter, charge_dtl, sf_charge_summary and related tables carry vendor-specific quirks — null-safe joins, signed amounts that distinguish charge vs contra, encounter merges that mean the same patient encounter can appear under multiple encounter IDs after a chart correction, and Sunrise Financial Manager overlays that adjust the underlying charge_dtl row without a clear audit trail. The validation engine handles each: null-safe aggregation; signed-amount-aware sum reconciliation; encounter-merge-aware row count reconciliation that follows the encounter-merge log; and SFM-overlay-aware comparison that uses the SFM-adjusted value as the authoritative source-side amount. Allscripts DBAs reviewing the validation often comment that the engine catches edge cases their internal reporting misses. The same engine handles TouchWorks's distinct schema quirks and Practice Fusion's REST API pagination edge cases.

Per-facility, per-fiscal-period reconciliation typically runs in 20-40 minutes against a multi-facility IDN's full year of Allscripts data. Family one (row counts) is the fastest — minutes. Family two (sum totals across charges, supply consumption, asset values) takes 5-10 minutes per facility per period. Family three (per-record SHA-256 hash reconciliation) is the longest single step — typically 15-30 minutes per facility per period — but runs in parallel across facilities and periods. Family four (cross-source consistency between Sunrise / TouchWorks / Practice Fusion / dbMotion for the same encounter window) takes another 5-10 minutes per period. The full multi-facility validation run for a 5-hospital, 50-practice IDN typically completes in 4-6 hours overnight. Failures surface with field-level diagnostics ready for bulk fix in the next morning's standup.

Yes. Validation reads from the same read-only Sunrise Sybase/SQL Server replica, TouchWorks SQL Server replica, Professional EHR replica, Practice Fusion REST API and dbMotion views that extraction uses — never against the production OLTP. Where replicas are not available, validation can run against production in a throttled off-peak window with explicit Allscripts DBA approval, but the production-read path is rare. The validation engine respects the same rate limits the extractor respects: typically 5-10 DB connections per Sunrise replica, throttled REST calls against Practice Fusion (30 req/sec) and Veradigm Unity. Validation never writes back to source. The same engine handles Altera-managed Sunrise replicas for customers whose Sunrise moved under Altera Digital Health after the 2022 split.

A signed JSON + PDF reconciliation pack per facility per fiscal period. JSON: row counts per domain (encounters, charges, supplies, providers, assets) Allscripts side and Fusion side with delta; sum totals per domain with delta; SHA-256 hash reconciliation per partition with mismatch list; cross-source consistency checks per encounter window. PDF: human-readable summary with CFO sign-off page, CHRO sign-off page, biomed director sign-off page, privacy officer sign-off page. Failures surface with field-level diagnostics — which Fusion validation rule failed on which Allscripts row with which value. The deliverable is timestamped and KMS-signed and stored in the same immutable archive as the migration audit pack — it becomes part of the chain-of-custody evidence for any future HIPAA, Joint Commission or SOX audit.

dbMotion (Veradigm Connect) maintains a unified patient identity across Sunrise, TouchWorks, Professional EHR and external EHRs via its master patient index. The validation engine consumes the dbMotion patient-identity views read-only and uses them to reconcile cross-source consistency: an encounter that exists in Sunrise with a Sunrise-side MRN, in TouchWorks with a TouchWorks-side MRN and in Practice Fusion with a Practice Fusion-side patient_id should all map to the same dbMotion unified identity — and therefore to the same KMS-pseudonymized token on the Fusion side. Mismatches surface as reconciliation failures with the dbMotion identity audit trail attached, so the privacy officer and patient-identity team can investigate the source-side identity issue. This catches a class of error that traditional row-count validation misses entirely and that often goes undetected until a clinical incident exposes it.