2.9 EDI trading partners and submission routing

Outcome

Outbound 837s are correctly enveloped (ISA/GS/ST), routed to the right trading partner, and inbound 277CA / 835 / 271 files are picked up and posted.

Prerequisites

• 2.8 Ingestion complete.
• The customer has provided their submitter ID and credentials with each clearinghouse / payer.

EDI envelope hierarchy

SFTP / X12 partner setup at a glance

All partner screens are in the EDI console (Configuration → Trading Partners, Configuration → Routing Rules), not the Platform Admin console. There is no per-customer submitter-ID screen and no per-customer envelope screen.

Steps

1. Register the trading partner (master DB, platform action)

   Most clearinghouses are already in the master rcm_master.trading_partner table. If the customer uses one not yet registered, add it in the EDI console:

   Configuration → Trading Partners → New partner

   Field	Example (Availity)
   Name	Availity
   Partner type	Clearinghouse
   Protocol	SFTP
   Host	files.availity.com
   Port / Username	not yet supplied by Availity — see the runbook
   Inbound root directory	/MILLIN/MILLIN, with one declared directory each for CLAIMS/OUTPUT (999), ERA/OUTPUT (835) and STATUS/OUTPUT (277)
   Outbound	837P and 837I → /MILLIN/MILLIN/CLAIMS/OUTPUT
   Envelope profile / sender ID	availity / AV09311993
   Transport modes	BATCH_SFTP

   Availity is one shared partner row for every customer. Do not create a row per customer. The full Availity procedure — every field, the batch cap, the host-key pin, the credential and the open vendor questions — is section RCM-14 of the engineering runbook (docs/operations/runbook-rcm.md in the repository). Follow that, not this summary, when you configure it.

   Availity on a multi-customer install

   With two or more active customers, the scheduled poll takes only .999 files from Availity; .835 and .277 files stay on the server. That is an open owner decision (runbook RCM-14.7). Check it before promising a customer ERAs from this lane.

   Credentials live in Key Vault, not in this row. Set them on the partner's Credentials tab (see Trading partner credential vault).

2. Confirm the customer's submitter identity

   There is no submitter-ID screen. What identifies the customer depends on the partner's envelope profile:

   • Availity (availity profile): the interchange sender (ISA06 AV09311993) and receiver (ISA08 030240928) are shared by every customer and set on the partner row or in code. The customer's own identity travels in each claim's 1000A submitter loop, taken from the customer's billing entity name and NPI. Confirm those are right in the customer's billing-entity setup; there is nothing to enter per partner.
   • Claim.MD (claim-md profile): ISA06 is the customer's own Claim.MD account number, held on the customer's clearinghouse account binding (runbook section RCM-13), not on the partner row.

3. Envelope values are not a per-customer setting

   There is no envelope screen. The interchange and group identity come from the partner's Envelope profile (see step 1). Companion-guide rules cannot reach the ISA or GS segments, because the envelope is built before they run. The platform builds the envelope; never hand-edit X12 in the database.

4. Define submission routing rules

   EDI console → Configuration → Routing Rules → new rule

   Field	Example
   Claim Type / TX Type	P / 837P
   Dispatch Mode	BATCH_SFTP
   Payer ID	OH054, or blank for any payer
   Customer	blank for any customer, or one customer to route only them
   Trading Partner	Availity
   Priority	100
   Effective From	2026-01-01

   Multiple rules can match. A rule scoped to a customer wins over an otherwise equal unscoped rule, and priority breaks remaining ties. Use the precedence simulator on the Routing Rules page to check which rule wins.

5. Optional: configure companion-guide overrides

   For payers with their own quirks (Ohio MITS, Indiana Medicaid, etc.), the master DB ships companion-guide rules (EDI console → Configuration → Companion Guides). Override only if the customer has a non-standard contract.

6. Run a partner test cycle

   Most clearinghouses require a test certification before flipping to production:

   1. Agree the test window and the test-versus-production indicator with the partner. The console has no test-indicator toggle.
   2. Submit a small test claim batch (3–5 claims).
   3. Wait for the partner's TA1/999/277CA acknowledgments.
   4. Iterate until clean.
   5. Get partner approval (email confirmation typically).
   6. Re-test with one production claim.

Validation

Check	Expected
rcm_master.trading_partner row	exists for every partner the customer uses (one shared row for Availity)
Test connection → Run test on the partner's Connection tab	Connection healthy
Submission routing	the precedence simulator shows the correct partner for each payer
Test partner cycle	partner-issued go-live approval

Troubleshooting

Symptom	Likely cause	Fix
Outbound 837 rejected with TA1 error	ISA segment misformatted	Inspect the file in EDI console → Transactions → <transaction> → Raw Payload; compare to companion guide.
999 with status R	Functional ack rejected	Read the AK3/AK4 segments — they identify the offending segment + element.
277CA A2 — Acknowledged for some, A6 — Rejected for others	Per-claim issues, not envelope	Drill into the rejected claim's STC segment for the reason code.
Inbound 835 sits in Receivables → Uncategorized	Payer ID mismatch on payment	Confirm the BPR06 payer identifier matches rcm_master.payer.electronic_payer_id.

Next

2.10 — Users and RBAC