EDI, or Electronic Data Interchange, is the computer-to-computer exchange of standard business documents between healthcare organizations. It replaces paper-based administrative tasks like mailing insurance claims, checking patient eligibility, and processing payments with automated electronic transactions. Nearly every billing interaction between a doctor’s office and an insurance company now flows through EDI, and federal law requires it for most covered entities.
How EDI Works in Practice
The simplest way to understand EDI is to follow a medical claim from start to finish. After a patient visit, the provider’s billing system packages the encounter data into a standardized electronic file called an 837 transaction. That file doesn’t usually go straight to the insurance company. Instead, it passes through a healthcare clearinghouse, which acts as a translator and quality filter between providers and payers.
The clearinghouse performs several checks before the claim moves forward. It verifies the patient’s insurance is active for the date of service, validates the file’s structure against federal formatting rules, and reviews diagnosis and procedure codes for logical consistency. It also checks payer-specific requirements like prior authorization indicators. Claims that pass these checks are grouped into batches and transmitted securely to the insurance company. Claims that fail get kicked back to the provider with specific error codes so staff can fix and resubmit them.
Once the payer receives a clean claim, it moves into adjudication, where the insurer determines how much to pay. After that decision, the payer sends back an Electronic Remittance Advice (ERA) detailing the payment. The clearinghouse translates that response and delivers it to the provider’s system for automated posting and reconciliation. Throughout this process, automated status inquiries let providers track where a claim stands from submission through final disposition.
Common EDI Transaction Types
Healthcare EDI isn’t just about claims. It covers a range of administrative exchanges, each identified by a standard transaction code:
- 837 (Health Claims): The most common transaction. Covers institutional, professional, and dental claim submissions from providers to payers.
- 835 (Electronic Remittance Advice): The payer’s response explaining what was paid, denied, or adjusted on a claim.
- 270/271 (Eligibility Verification): A provider sends a 270 inquiry asking whether a patient has active coverage, and the payer responds with a 271 containing benefit details.
- 276/277 (Claim Status): Lets providers check where a submitted claim stands in the payer’s processing pipeline.
- 278 (Prior Authorization): Used to request and receive approval for services that require pre-authorization.
- 834 (Enrollment/Disenrollment): Handles adding or removing members from a health plan.
- 820 (Premium Payment): Transmits employer premium payments and explanations to health plans.
Retail pharmacy transactions use a different standard from the National Council for Prescription Drug Programs (NCPDP) rather than the X12 format used for everything else.
HIPAA Requirements for EDI
HIPAA didn’t just create privacy rules. It also mandated national standards for electronic healthcare transactions to bring consistency to a system that previously had hundreds of competing formats. Any provider who accepts payment from any health plan or insurance company and conducts transactions electronically must comply with these standards. That applies broadly, not just to providers who accept Medicare or Medicaid.
The current mandated format is ASC X12 Version 5010, which has been in effect since January 2012. All HIPAA-covered entities, including health plans, clearinghouses, and providers, must use this version. Providers are also required to have written agreements ensuring their business associates (like clearinghouses and medical transcription services) comply with HIPAA as well.
Some transactions also have federally mandated operating rules that go beyond the data format itself. Eligibility verification, claim status inquiries, electronic remittance advice, and electronic funds transfers all have operating rules that standardize things like response times and acknowledgment procedures. These operating rules took effect between 2013 and 2014, depending on the transaction type.
Cost Savings Over Paper Processing
The financial case for EDI is straightforward. According to data compiled by the Maryland Health Care Commission using CAQH Index figures, submitting a claim electronically costs a provider about $1.19 per transaction compared to $2.52 for a manual paper claim. On the payer side, the gap is even wider: $0.08 per electronic claim versus $1.18 for manual processing.
That works out to a per-transaction savings of $1.33 for providers and $1.10 for payers, or $2.43 combined. Multiply those numbers across millions of claims per year, and the system-wide savings are enormous. Beyond the direct cost per claim, EDI reduces postage, printing, and materials handling while cutting down on the back-and-forth caused by errors that clearinghouses catch before submission.
How EDI Data Stays Secure
Because EDI transmissions carry protected health information, security during transit is critical. The most widely used transmission protocol in healthcare EDI is AS2, which sends data over HTTPS with digital certificates and encryption. AS2 also supports signed receipts, so the sender gets confirmation that the recipient actually received the file.
Other common options include SFTP (Secure Shell File Transfer Protocol), which encrypts all commands and data so nothing travels in plain text, and FTPS, which wraps standard file transfers in an encryption layer. Some organizations use VPNs for additional protection. The clearinghouse-to-payer transmission step in the claims workflow typically relies on AS2 or SFTP connections.
EDI vs. Clinical Data Exchange
EDI handles the administrative and financial side of healthcare: claims, eligibility, payments, and enrollment. It is not designed for exchanging clinical information like lab results, medication orders, or patient records. That role belongs to a different set of standards, primarily HL7, which enables real-time clinical communication between systems like electronic health records, lab information systems, and pharmacy platforms.
A newer standard called HL7 FHIR is increasingly bridging the gap between these two worlds. FHIR uses modern web-based technology (APIs) to exchange both clinical and administrative data, and it’s designed to work alongside existing infrastructure rather than replace it entirely. For now, though, the core administrative transactions that keep the billing cycle running still flow through X12 EDI. A newer version of the X12 standard, version 8010, has been developed and includes expanded capabilities like claims pre-determination, but CMS has not yet mandated a transition date from the current 5010 version.