Electronic Data Interchange
ediDefinition
ISO-11179 Definition
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.
Standard Abbreviation
edi
Category
Production DDL — DIM_SYSTEM
CREATE OR REPLACE TABLE DIM_SYSTEM (
sys_key INTEGER NOT NULL -- surrogate key,
sys_id VARCHAR(50) NOT NULL -- system identifier,
sys_nm VARCHAR(200) NOT NULL -- system name,
sys_type_cd VARCHAR(50) -- system type code,
sys_vrsn VARCHAR(50) -- system version,
vndr_nm VARCHAR(200) -- vendor name,
intfc_type_cd VARCHAR(50) -- interface type code,
intfc_proto_cd VARCHAR(20) -- interface protocol,
env_cd VARCHAR(20) -- environment code,
host_nm VARCHAR(200) -- hostname,
ip_addr VARCHAR(45) -- IP address,
sts_cd VARCHAR(20) -- status code,
eff_dt DATE NOT NULL -- effective date,
exp_dt DATE -- expiration date,
rec_creat_dt TIMESTAMP NOT NULL -- record created date
);
Standard Snowflake DDL for the canonical technology table. Convert to BigQuery or Databricks →
Why This Term Matters
Healthcare data terminology is foundational for any data engineer working in this industry. Precise understanding of standard terms enables accurate schema design, reduces downstream data quality issues, and ensures pipelines meet the regulatory and interoperability requirements imposed by HIPAA, HL7 FHIR, and CMS reporting frameworks. Without this foundation, even technically well-built pipelines produce data that fails validation when it reaches payers or regulators.
Related Content
Looking for more healthcare terms?
Browse our complete library of 100,000+ standardized healthcare data terms
Browse All Terms