An integration platform: the legacy claims integration replaced

Homegrown EDI shredding into a normalized datamart before adjudication.

I led the replacement of Microsoft BizTalk with homegrown EDI shredding directly into a normalized datamart before adjudication. Capturing complete claim data reduced enhancement turnaround by 50% and improved received-to-paid mapping and CMS reporting. The LifePRO engine replacement, daily reconciliation and paper-to-EDI conversion were separate projects.

Homegrown EDI shredding into a normalized datamart before adjudication; 50% shorter enhancement turnaround.

My role: I led the replacement of Microsoft BizTalk with homegrown EDI shredding directly into a normalized datamart before adjudication. The inputs included CMS COBA files and Emdeon-provided VA claim inputs. Capturing complete claim data reduced enhancement turnaround by 50% and improved received-to-paid mapping and CMS reporting. The LifePRO engine replacement, daily reconciliation and paper-to-EDI conversion were separate projects.
The decision: Replace Microsoft BizTalk with homegrown EDI shredding directly into a normalized datamart before adjudication, keeping LifePRO replacement, daily reconciliation and paper-to-EDI conversion separate.
The result: Capturing complete claim data reduced enhancement turnaround by 50% and improved received-to-paid mapping and CMS reporting. The data landed directly in a normalized datamart before adjudication.

The role, scope and reported outcome above are from my experience. The requirements, designs, thresholds and review records below are portfolio samples that illustrate the decisions. They are not employer documents or historical sign-offs; some shared tables cover the whole intake product.

Product design / Process flow

Microsoft BizTalk → homegrown EDI shredding

01
Define the first capability
Consumer needs · transaction contract · ownership
Choose a bounded first use case and make the compatibility requirement explicit.
Exception:
Scope keeps expanding?
Recovery:
Protect the first usable increment and record deferred capabilities.
02
Build the product core
Adapters · validation · routing · observability
Separate reusable platform responsibilities from consumer-specific mappings.
Exception:
Unowned exception?
Recovery:
Define resolution and recovery before adding another consumer.
03
Prove equivalence
Contract tests · reconciliation · recovery rehearsal
Compare old and new outcomes without creating duplicate live transactions.
Exception:
Unexplained mismatch?
Recovery:
Stop the cutover and investigate the difference.
04
Introduce & operate
Controlled cutover · support · rollback · adoption
Make production ownership, recovery and consumer adoption part of the product.
Exception:
Quality or service degrades?
Recovery:
Pause expansion; reconcile in-flight work before rollback.

An illustrative migration flow for replacing Microsoft BizTalk with homegrown EDI shredding into a normalized datamart before adjudication.

1 / 4 · Retain, buy or build

How was the platform kept a separate investment?

Portfolio sample
Product strategy · Chosen approach

I choose bounded automation with reviewable exceptions. Define input quality first, establish provider resolution next, then validate downstream handoff and reconciliation. A platform replacement remains a separate investment: its migration scope follows consumer dependencies, rather than being bundled into the OCR rollout for convenience.

Portfolio sample
Product strategy · Three investments, three choices

These retrospective comparisons keep the product intent distinct for each experience.

Product	Alternative and constraint	Chosen direction / recheck
Claims intake	Manual entry scales with effort; OCR-only shifts unresolved work downstream; end-to-end automation adds integration and exception cost.	Automate a supported claim path with validation and an accountable review route; inspect net effort after rework.
Provider resolution	Formatting-only cleanup cannot supply missing identity evidence. Individual consumer lookups duplicate logic. A shared API introduces source availability and versioning dependencies.	Normalize representation and resolve against a central authorized source; retain ambiguity and source freshness in the contract.
Integration platform	Retain/extend the legacy platform for lower near-term change; buy a replacement for vendor support; build internally for control with engineering/operating responsibility.	The experience was leading the replacement of a legacy claims integration with an enterprise claims processing solution. Evaluate adoption, contract coverage and ownership separately from the OCR business case.

Read the complete sample
Product strategy →

What evidence earns a cutover?

Portfolio sample
Options & decision record · Reversibility changes the release evidence

A UI label or additional diagnostic view is readily reversible. Changing provider identity rules or moving live traffic has downstream consequences that a simple code rollback may not undo. I therefore require outcome reconciliation, explicit ownership and a bounded first consumer before expanding a platform transition.

Read the complete samples
Dial-up & rollback → Go / No-Go decision →

Related evidence

Keep exploring.

All healthcare documents →

01 · Retain, buy or build

Why build the replacement?

Portfolio sample
Options & decision record · Integration platform — retain, buy or build?

My experience was leading the replacement of a legacy claims integration with an enterprise claims processing solution. The comparison below is a sample investment decision, not a procurement record.

Option	Why consider it	What must be proven
Extend the legacy platform	Protect near-term continuity	Ongoing cost and limitations remain acceptable.
Buy a replacement	Vendor-supported capability and ecosystem	Fit, integration effort, portability and operating cost.
Build internally	Control over product contracts and sequencing	Staffed ownership, contract coverage, recovery and consumer adoption.

Portfolio sample
PRFAQ · Internal FAQ: why buy, build or partner?

Why partner for extraction? Supported-form expertise and document-processing capability can reduce initial implementation work, provided the vendor contract exposes uncertainty, evidence and recoverable errors. Why build the provider interface? A central resolution contract can make normalization and failure semantics consistent for consumers. Why not replace the integration platform at the same time? A platform build changes operational ownership and consumer behavior; it needs its own cost, continuity and migration decision. The 0→1 replacement experience informs that decision without being treated as an OCR dependency.

Read the complete samples
Options & decision record →
PRFAQ →

What can be claimed, and what cannot?

Portfolio sample
Annual review · Outcome attribution

Workstream	Outcome	Basis
Mailroom digitization	400,000+ claims converted; 80-person team redeployed; about $1M a year	Program outcome
Reconciliation	300,000 missing claims and about $10M found; daily audit	20-million-claim analysis
Provider identity	99% match against the master; legacy matching retired	Proof of concept
Engine replacement	Homegrown EDI shredding into a normalized datamart before adjudication; 50% shorter enhancement turnaround.	Post-replacement measures

Portfolio sample
GTM strategy · Value proposition and limits

I position the product around reliable administrative completion, not guaranteed payment or clinical improvement. More than 400,000 paper claims were converted to EDI 837, an 80-person team was redeployed and the business saved about $1M a year. The separate provider interface improved latency and reporting; the platform work replaced a legacy claims integration. Those outcomes support different conversations and are not bundled into a single ROI claim. Medical 837 and retail pharmacy NCPDP workflows remain distinct.

Read the complete samples
Annual review → GTM strategy →

← Back to Work