EDI Healthcare

EDI is Commonly Used to insure accurate Data Transmission in Healthcare

What is EDI Healthcare?

Electronic Data Interchange (EDI) for healthcare  requires EDI software that provides a structural and compliant way to securely transmit data between healthcare providers, plans, payers, clearinghouses, third party administrators (TPAs), and other healthcare software companies (intermediaries). EDI healthcare transactions are based on a standardization governing body X12.org conforms to HIPAA mandated national standards.

How is EDI different for healthcare?

Large EDI files - EDI healthcare transactions such as claims (837I, 837P) and monthly enrollment 834 snapshots tend to be much larger than typical supply chain EDI transactions. That’s why it’s important to look for software that’s built for EDI healthcare. You will find that EDI software built for the masses will try to put in work-around methods such as EDI file splitting and non-scalable integration patterns. Even worse, some of the EDI solutions parse EDI into XML or similar bloated in-memory structure. This will increase the payload of the ANSI EDI file many times over and cause slow performance.

Key terms differentiating healthcare EDI


According to HIPAA, all healthcare clearinghouses and health plans should use the National Provider Identification Standard (NPI) to identify covered providers. It’s a unique identification for providers. The 10-digit number is a surrogate key that has no meaning outside of an assigned number.

WEDI SNIP Level Edits

A major difference for EDI healthcare transactions is a system capable of industry WEDI SNIP Level Edits. At the minimum, an EDI healthcare system should provide SNIP levels 1 and 2.

PHI data security

HIPAA mandated security measures to protect patient identifying data elements. Your EDI healthcare system should provide the necessary functions to secure and protect patient information.

999, not 997

It’s always interesting to see a company offering EDI healthcare solutions and mention 997 Acknowledgements (ACK). All HIPAA compliant systems should be providing 999 as mandated by the 5010 standard.

5010, not 4010

Again, when you talk to EDI healthcare vendors and they mention 4010, it’s an indication they focus on supply chain and other non-healthcare EDI solutions. In order to be HIPAA compliant, EDI healthcare companies should be using 5010 standards.

What HIPAA transaction sets are specific for EDI healthcare?

Here are a few EDI healthcare transaction sets:

  • 837I – An EDI 837I is an X12 Institutional Claim. This is billing from hospitals and other in-patient and out-patient providers. It takes the form of UB04 and 837I X12 EDI. 837P – Professional Claim is billing by physicians, medical offices, suppliers, and other non-institutional providers. It takes on the form of a CMS1500 and 837P X12 EDI.
  • 837D – Dental claim billings are sent as ASC X12 EDI 837D files by dental providers.
  • 834 – Member Enrollment ASC X12 EDI file provides maintenance and enrollment information for plans. It includes new, change, delete, and reinstatement enrollment records.

What is HIPAA and how does it apply to EDI?

HIPAA stands for Health Insurance Portability Accountability Act and was put into legislation to protect patient’s medical information. It outlines provisions and security measures to handle healthcare data.

What is PHI?

The HIPAA security provisions outline how Protected Health Information (PHI) should be safeguarded. Compare EDI software that follows these guidelines to help your organization protect a patient’s past and current medical condition is secure and protected. Any patient data that can reasonably identify the person should be secured. Examples of PHI data elements include name, birth date, address, and social security number.

Challenges with Processing Healthcare EDI:

  • Large EDI files – Large 834, 837 files can be difficult scale without a proven EDI healthcare system.
  • Protecting PHI data – According to HIPAA compliance, an EDI healthcare platform should provide protection and security of patient information. Complex standardized rules – WEDI SNIP level edits should come out-of-the-box with EDI healthcare solutions.
  • Complex custom rules – Plans, TPA’s, and other healthcare EDI software companies should provide a framework to implement customized rules for rulesets such as member matching, custom enrichments, and other custom business rules.
  • Member matching – Matching a member requires complex logic. Implementing a “fuzzy match” for existing members can be challenging for EDI healthcare solutions.
  • Non standards - Source and destination system formats that are non-standardized can be difficult to transform.

EDI Healthcare specificity

When choosing an EDI Software or EDI Managed Services, ask your vendor the following questions.

  1. Can you show WEDI SNIP Rule support (SNIP 1, 2 minimum)?
  2. How are elevated SNIP edits implemented, such as SNIP 3?
  3. How long will it take to install the EDI healthcare software; how invasive?
  4. Will the EDI healthcare system scale and how does it handle extremely large 834 and 837 files?
  5. How is PHI data handled in the EDI healthcare platform?
  6. Are there alternatives such as Product Software, Hosted, SaaS, and Managed Services offerings?
  7. Was this EDI software originally developed for healthcare?
  8. How much will professional services cost?
  9. Does it take more than 3 days to onboard a trading partner?