Electronic data interchange (EDI)

What electronic data interchange is

Electronic data interchange is the plumbing that moves billing and admin data between your system, the clearinghouse, and the payer. In U.S. healthcare it usually means HIPAA X12 transactions, a set of structured, coded files that software can create and read.

Common healthcare EDI transactions include:

• 837: claim submission (P = professional, I = institutional, D = dental)
• 270/271: eligibility and benefit inquiry and response
• 276/277: claim status inquiry and response
• 278: prior authorization request and response (less consistently used in behavioral health)
• 835: electronic remittance advice (ERA) and payment details
• 999 and 277CA: acknowledgments that your EDI file was accepted or rejected at the format and pre-adjudication level

Instead of staff keying claims or remits into dozens of payer portals, EDI lets your practice management or RCM system talk directly to payer systems using these agreed formats.

Why EDI matters operationally

EDI is where your revenue actually moves. If an 837 file fails, those claims are not in payer inventory and your days in AR increase, sometimes by entire cycles. If 835 files are not configured or read correctly, you cannot post cash accurately or see true denial patterns.

In a behavioral health setting, most volume is repeat and high-frequency: daily residential per diem, 3 to 5 days a week PHP or IOP, weekly outpatient therapy. Any EDI issue on an 837 can affect hundreds of dates of service at once. A single bad revenue code, place of service, or billing provider loop can create a wall of rejections that show up as CO-16 or pre-adjudication rejects in the clearinghouse.

EDI also impacts audit exposure. Sloppy configuration can cause inconsistent provider identifiers, mismatched taxonomy, or wrong billing NPIs that conflict with your credentialing and payer contracts. That invites more medical necessity review, payment holds, or retroactive recoupments once the payer notices patterns.

How EDI is used and read in day-to-day billing

In daily operations, your billing system creates an 837 file from charges, batches it, and sends it to the clearinghouse, which then routes to payers based on payer ID. The clearinghouse and payer EDI gateways send back acknowledgments like 999 and 277CA that confirm if the file and each claim passed basic checks.

A simple life cycle looks like:

• 837 sent from your system to the clearinghouse
• 999 returned to say the file structure is accepted or rejected
• 277CA returned to say each claim is accepted to payer inventory or rejected before adjudication
• 835 returned after adjudication with payments, adjustments, and denials

Most billers never open the raw X12 text. Instead, you read a clearinghouse or RCM dashboard that translates segments into "accepted," "rejected," or "paid/denied." What matters:

• Distinguish rejections in 999 or 277CA from true denials on the 835. Rejections were never in payer inventory.
• Tie each EDI response back to the original claim ID in your system so you know which claims to fix and resubmit.
• Watch for patterns in rejection reasons. A single mapping error in your behavioral health fee schedule or revenue code setup can quietly reject every residential claim for a month.

On the remittance side, the 835 is where you see allowed amounts, patient responsibility, and denial reason codes. Your system parses CARC and RARC codes from the 835 into human-readable categories. If 835 enrollment is not completed for a payer, you lose that automation and have to rely on paper EOBs or portal downloads, which slows cash posting and hides denial trends.

• Treating clearinghouse or 277CA rejections as true payer denials, so they never hit your denial reporting and quietly extend days in AR for an entire batch of residential or PHP claims.
• Not monitoring 999 and 277CA acknowledgments, which lets a failed 837 file sit unnoticed for weeks until someone notices missing payments and then runs into timely filing problems.
• Using the wrong payer ID or payer enrollment for behavioral health carve-outs, so EDI sends mental health claims to the medical carrier and returns a CO-16 or off-system rejection instead of routing to the behavioral vendor.
• Failing to sync system configuration to payer EDI companion guides, for example using an unsupported revenue code or place of service for IOP, which causes every claim in that level of care to reject pre-adjudication.
• Changing billing NPIs, addresses, or tax IDs without updating EDI enrollments and trading partner setups, which leads to mixed identities across 837 and 835 files and triggers credentialing or audit issues with payers.

Behavioral health programs face more EDI fragmentation than many medical practices. Benefits are often carved out to a separate behavioral health payer, or split between a medical plan and a specialty vendor. That creates multiple payer IDs, multiple EDI enrollments, and sometimes separate clearinghouse connections just to reach the right entity.

Concurrent authorization and visit caps also create complexity. Even when your 837 passes EDI checks, units that exceed an authorization span can still deny as CO-197 at adjudication. Some payers use 278 EDI for authorizations, but many behavioral health vendors push you into portals instead. The result is an EDI claim stream that is technically clean, but financially exposed if your system does not sync auth spans to units on each claim.

Long per-diem episodes, like 60- or 90-day residential, mean a single 837I file can carry many room-and-board and ancillary lines. If a payer or Medicaid MCO updates its institutional companion guide for revenue codes, patient status codes, or occurrence codes and your system does not follow, you can suddenly see entire episodes kicked out at the 277CA stage. With state Medicaid and MCO payers, there are often state-specific EDI quirks for behavioral health that do not apply on the medical side, so relying on a generic "hospital" or "clinic" template is risky.

For outpatient therapy and IOP/PHP, volume is high and rates are thinner. Even a small spike in rejections, for example a place-of-service rule change for telehealth, can erase a week of margin. Tight EDI monitoring and clear mapping between CPT/HCPCS, modifiers 95 or 93, and each payer's telehealth rules is critical to keep those units paid on time.

For EDI, AI can watch the firehose of acknowledgments and remittances in a way humans simply do not have time to do. An agent can read every 999, 277CA, and 835, group issues by payer, program, or level of care, and flag when a new rejection pattern starts to hit your residential or IOP claims. It can also translate raw EDI and CARC/RARC codes into clear work queues, like "fix payer ID for all Optum BH claims after 10/1" or "rebuild IOP place-of-service mapping for Medicaid MCO X."

Supabill runs agents that sit on top of your clearinghouse and remittance feeds. A claims-scrubbing agent can apply stored payer rules before the 837 is sent, and a denials agent can classify every 835 line by CARC/RARC and group-code into operational buckets. The limit is configuration and judgment: a human still has to decide when to contact a payer to update EDI enrollment, when to change billing provider strategy for a program, or when to stop submitting via EDI at all and move a specific edge case to paper or portal until the trading partner issue is fixed.

Is EDI required for behavioral health claims?

HIPAA requires standard formats for electronic claims, but it does not require every provider to submit electronically. Many commercial plans and Medicaid MCOs strongly prefer or require EDI for high-volume services like outpatient therapy, residential, PHP, and IOP because it reduces manual work on their side.

What is the difference between a clearinghouse and EDI?

EDI is the standard file format and protocol, for example the 837 or 835 X12 file. A clearinghouse is the intermediary that receives your EDI files, checks them, and routes them to payers, then returns acknowledgments and remits back to you.

How do I know if my EDI claim was rejected or accepted?

You should see 999 and 277CA acknowledgments from the clearinghouse or payer. In your clearinghouse portal or RCM system, those show as batch-level and claim-level statuses, such as "accepted," "rejected," or "accepted to payer." If a claim never progresses past rejected status, it was not in payer inventory and needs correction and resubmission.

Do I still need paper EOBs if I get 835 electronic remittances?

Most providers that have 835 set up do not need paper EOBs for routine posting, since the 835 contains payment, adjustment, and denial details. Some keep paper or PDF EOBs from certain payers for audits or edge cases, but well-configured 835 posting and storage is usually enough operationally.

How long should I keep EDI files?

Operationally, many organizations keep EDI and remittance data in their billing system or data warehouse for several years for audits, appeals, and trending. The exact retention period should follow your organization's record retention policy and any state or contract requirements.

• X12, About