Legacy stacks treat EDI as per-customer plumbing — a trading-partner project per customer, a stored procedure per payer, a script per recovery. The new platform centralises EDI behind canonical events and surfaces every operation as a configuration action.
Twelve transactions cover the eligibility / authorization / claim / remittance lifecycle plus the acknowledgments. Each is implemented end-to-end — not deferred to a future release.
The application never builds X12. It publishes canonical events to rcm.* Service Bus topics; consumers in the EDI gateway translate to 837 / 270 / 276 / 278 and dispatch by routing rule. Inbound X12 is parsed back into canonical events and re-published.
A new payer's EDI capability is enforced at config time, not discovered in production. Routing rules match against state, payer, payer-type, service-line, claim-type, transaction-type, dispatch-mode, and effective dates.
Each routing rule has a precedence score and an effective date.
The /routing simulator returns the winning rule
and the losing rules for any given inbound
claim — so "why did this claim go to clearinghouse A instead of
B?" is a click, not an investigation.
Transport modes are first-class: SFTP, REST, AS2, MFT, and a manual fall-back for trading partners that still require an email attachment. Credentials never traverse the application surface — they live in Azure Key Vault and only the edi-gateway worker sees them at dispatch time.
This makes 'we lost a batch' a UI click instead of an incident.
Dead-letter queue visibility per consumer + exponential backoff + idempotent re-submit. "We lost a batch" used to be an incident with a war-room call and a SQL recovery script. Now it's a row in the replay surface with a button.
The companion-guide editor pairs a Monaco YAML pane with a live preview that re-assembles a sample 837 or 270 as you type. Rules are scoped per partner + transaction type; a bad edit fails the validator before production.
COMPANION_GUIDE_VALIDATE + PRE_SUBMIT_VALIDATE run inside the EDI flow.
ReferencePayer registry, companion guides, NPPES — all referenced during EDI assembly.
TrustTrading-partner credentials sealed in Key Vault — never on the application surface.
