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

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:

   Admin → Trading partners → Add

   Field	Example
   Name	Availity
   Partner code	AVAILITY
   Connection config	{ "protocol": "SFTP", "host": "ftp.availity.com", "port": 22, … }
   Inbound path	/inbound
   Outbound path	/outbound

   Credentials live in Key Vault, not in this row.

2. Configure the customer's submitter ID with each partner

   Impersonate the tenant → Admin → EDI → Submitter IDs → Add

   Field	Example
   Trading partner	Availity
   Submitter ID	ACME001 (provided by the customer)
   Submitter name	Acme Behavioral Health
   Receiver IDs	one row per payer routed through this partner

3. Set the X12 envelope defaults (per partner + tx type)

   Admin → EDI → Envelopes → Add

   Field	Example
   Partner	Availity
   Tx type	837P
   ISA sender ID	ACME001
   ISA sender qualifier	ZZ
   ISA receiver ID	030240928 (Availity prod)
   GS application sender	ACME001
   GS version	005010X222A1
   Acknowledgment requested	yes
   Test indicator	T (test) or P (production)

   The platform uses these to build the envelope; never hand-edit X12 in the database.

4. Define submission routing rules

   Admin → EDI → Submission routing → Add rule

   Field	Example
   Match	payer.electronic_payer_id = 'OH054'
   Route via	Availity
   Tx type	837P
   Effective	2026-01-01
   Priority	100

   Routing rules pick the cheapest valid route at submission time. Multiple rules can match — priority breaks ties.

5. Optional: configure companion-guide overrides

   For payers with their own quirks (Ohio MITS, Indiana Medicaid, etc.), the master DB ships companion-guide rules. 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. Set the envelope Test indicator = T in step 3.
   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. Flip envelope Test indicator = P and re-test with one claim.

Validation

Check	Expected
rcm_master.trading_partner row	exists for every partner the customer uses
Tenant edi.envelope_config rows	one per (partner, tx type)
Submission routing	dry-run shows 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 Admin → EDI → Outbound batches → <batch> → Raw; 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