Electronic Data Interchange

Electronic Data Interchange (EDI) in healthcare refers to the computer-to-computer exchange of standardized administrative and financial transactions between health plans, providers, and clearinghouses using formats mandated by HIPAA. The ASC X12 standards body defines the transaction sets used in healthcare EDI: 837P (professional claims), 837I (institutional claims), 837D (dental claims), 270/271 (eligibility inquiry and response), 276/277 (claim status inquiry and response), 278 (prior authorization), 834 (benefit enrollment), and 835 (remittance advice). All covered entities under HIPAA are required to use these standard EDI formats for electronic administrative transactions, making EDI the backbone of the US healthcare payment infrastructure.

Understanding EDI transaction structure is fundamental for healthcare data engineers because raw claims data, eligibility data, and remittance data arrive in these formats before any transformation into structured analytical schemas. An 837P transaction is a hierarchical text file using segment identifiers, element separators, and loop structures to encode the bill for a professional claim — claim header information appears in the CLM segment, diagnosis codes in HI segments, and service line details in SV1 segments. Parsing errors or misinterpretation of EDI segment logic are a common source of data quality problems in raw claims ingestion pipelines, particularly around multi-level loop structures (loop 2000A for billing provider, 2000B for subscriber, 2000C for patient, 2300 for claim, 2400 for service line).

Healthcare data engineers build EDI parsing pipelines using specialized EDI parsing libraries or custom parsers that transform raw X12 transaction files into structured staging tables, then apply business logic to normalize and validate the data before loading into the claims data warehouse. Key engineering tasks include handling ISA/GS envelope metadata for trading partner identification, parsing NM1 provider segments to extract NPI and TIN values, extracting CLM01 (claim ID), CLM02 (billed amount), and CLM05 (place of service/bill type), and mapping HI diagnosis segment qualifiers to distinguish principal, admitting, and other diagnosis codes. The 835 remittance transaction closes the payment loop, and reconciling 835 CAS adjustment reason codes against 837 billed amounts is essential for revenue cycle analytics and underpayment identification.