What is an X12 EDI Claim?
X12 EDI is the primary electronic format standard for medical claims data exchange in the insurance portion of the healthcare industry.
Despite being over 45 years old, X12 EDI remains the main method by which claims are transmitted between entities to manage medical payments. “Clearing house” entities are responsible for exchanging this information between payers and a providers electronic medical record system. It is also used for prior authorizations.
To view info on other healthcare electronic formats, see our blogs on HL7v2 ADT, HL7 CDA, or HL7 FHIR.
A portion of an 837 X12 EDI Healthcare Claim
Some additional information:
X12 EDI messages are strings of text. The spec does not define how they are to be transferred, just structured. There are about 300 transaction types, only 20 of which are used for healthcare.
The X12 spec is a closed standard. This means there are no complete open source tools to digest or manipulate them. You must have the file, plus a paid-for X12 schema describing the file to interpret it, with software to do so. Or, you can work with a vendor like Tenasol.
HL7v2 ADT was largely built off the X12 EDI standard. There are heavy similarities in how the two are structured. X12 EDI has more segment types, whereas HL7v2 ADT has more basic data types. However, HL7v2 is public.
X12 EDI can be converted to FHIR. Just like HL7v2 ADT, messages, X12 messages contain healthcare data that may be converted into FHIR resources and bundles with a vendor like Tenasol.
X12 EDI Claim Structure
The structure of X12 EDI files is more complicated than HL7v2 ADT. Of the 300 transaction types, each is narrowly defined in how they are structured.
Transactions are the main unit. A group of transactions may be sent together in a “Functional Group“. A group of functional groups is called an “Interchange“. There are about 300 transaction types.
Loops are subdirectories inside of transactions which may repeat. They are viewed within the context of their parent data outside of them. Loops can contain loops. The loops in a transaction are defined by the transaction type.
Segments are dictionary elements with key-value pairs. For example, a patient segment describes their name and address across multiple fields. There are about 1000 segment types.
Basic Datatypes are the the types of data that make up segments. these include string, numeric, decimal, date, time, id (code), and binary.
Data in an X12 Claim
While many transaction types exist, the 837 (claim) and 835 (response) are the most commonly used.
One unique aspect of a claim is that they are subscriber-focused not patient-focused as payment is the focus, not so much care.
A 837 EDI X12 claim has over 2000 unique fields containing:
Who the subscriber is
the subscribers insurance details
the patient, and their relationship to the subscriber
all practitioners involved
all facilities involved
information associated with the care that triggered the claim
transport information
itemized codes and costs of care rendered
An 835 has 500 unique fields containing
adjudication information
practitioners involved
X12 to HL7 FHIR
X12 EDI conveniently may be converted to HL7 FHIR via Tenasol. Ane example is available in our FHIR viewer. There is no standard specifying how to do this, in part because of the X12 specifications private nature. Tenasol has custom built a solution to this and uses the full array of FHIR resources without leaving out detail.
Conversion of an 837 claim to FHIR (Bundle) by Tenasol
We have taken the time to convert the following transactions via API or bulk transfer:
267 Individual Life, Annuity and Disability Application
269 Health Care Benefit Coordination Verification
270 Eligibility, Coverage or Benefit Inquiry
271 Eligibility, Coverage or Benefit Information
274 Healthcare Provider Information
275 Patient Information
276 Health Care Claim Status Request
277 Health Care Information Status Notification
278 Health Care Services Review Information
500 Medical Event Reporting
834 Benefit Enrollment and Maintenance
835 Health Care Claim Payment/Advice
837 Health Care Claim
837P Health Care Claim - Professional
837I Health Care Claim - Institutional
Clients interested in converting X12 EDI to FHIR can benefit from substantial growth of their HL7 FHIR data lake, especially when combined with Tenasol’s other HL7 FHIR transformation services for PDF data, ADT / HL7v2 data, and CCDA data, and be able to perform graph data analysis.
X12 to Other Formats
It is a rare need to convert X12 EDI to HL7v2 (ADT) or HL7v3 (CDA). This is because the latter two formats are typically used for different purposes. HL7v2 is more common within the provider domain, whereas X12 EDI is more common in the payer domain. They also typically focus on different information, so have little overlap and therefore conversion is of little use. To view more information on medical data format conversion see our blog on the subject.
Conclusion
X12 EDI remains a cornerstone of medical data exchange, especially in the payer segment of the healthcare industry. Despite its age and the complexity of its closed specification, it continues to power the transmission of critical claims and administrative data. With limited overlap between X12 EDI and provider-facing standards like HL7v2 or HL7v3, the most valuable transformation pathway today is from X12 to HL7 FHIR. This unlocks modern interoperability, analytics, and patient-centric care workflows.
While working with X12 can be daunting without access to the full specification, solutions like Tenasol simplify the process by converting key transaction types into clean, usable FHIR resources. As healthcare continues to evolve toward value-based care and integrated ecosystems, enabling X12 data to participate in broader FHIR-based data lakes will be essential for insights, automation, and better health outcomes. For teams seeking to bridge legacy and modern standards, X12-to-FHIR conversion offers a powerful path forward.