<img alt="" src="https://secure.leadforensics.com/150446.png " style="display:none;">

EDI Unleashed – Series 5

Supriya Sonavane Jan 21, 2013

Electronic Data Interchange EDI messages healthcare EDI messages Healthcare EDI HIPAA Technology

Till we’ve discussed about the fundamentals of EDI. We’ve also looked in to the benefits of Clearinghouses and the criteria for selecting Clearinghouse.

Now that we have a fundamental understanding of EDI, let’s get into the core of Health care EDI messages.

We shall also look into the technical aspects of generating these messages at a later stage.

The Health Insurance Portability and Accountability Act (HIPAA) were enacted by the U.S. Congress in 1996.

Key EDI transactions are:

  • 837: Medical claims with subtypes for professional, institutional, and dental varieties.
  • 835: Electronic remittances
  • 820: Payroll deducted and other group premium payment for insurance products
  • 834: Benefits enrollment and maintenance
  • 270/271: Eligibility inquiry and response
  • 276/277: Claim status inquiry and response
  • 278: Health services review request and reply

These standards are X12 compliant, and are grouped under the label X12N 837P:

The 837P can be used to submit health care claim billing information, encounter information, or both, from providers of health care services either directly or via trading partner or Clearinghouse

Payers include, but not limited to:

  • Insurance company
  • Government agency (Medicare, Medicaid, CHAMPUS, etc.)
  • Health Maintenance Organization (HMO)

5,000 Claims per ST (limit is for CLM segment) can be transmitted at a time.

The 837 Professional Data Element Segment identifies the specific data content required by IBC/KHPE (Independence Blue Cross/Keystone Health Plan East).

IBC/KHPE Business Rules referenced in the Segment Usage Detail represent the following situations:

  • The element is required
  • The element is conditional and, when the situation exists, is required to be included
  • The element is conditional and, based on IBC/KHPE’s business, is always required by IBC/KHPE

Key segments which are a part of 837P message are as follows:

  • BHT: Beginning of Hierarchical Transaction
  • PRV: Billing/Pay to Provider Specialty Information
  • NM1: Billing /Rendering Provider Name
  • REF Billing Provider/Rendering Provider Secondary Identification/Service Facility Location Secondary Identification
  • SBR: Subscriber information
  • NM1: Subscriber/Payer/Patient name/Service facility location
  • CLM: Health claim information
  • PRV: Referring/Rendering Provider details
  • LIM: Drug details
  • CPT: Pricing details
  • CAS: Claims level adjustment
  • AMT: COB Payer paid amount/Patient responsibility mount
  • NTE: Claims notes

There will be a separate ISA-IEA set for each different type of transaction. For example, if an electronic transmission between two trading partners contains claims and authorizations, there will be two ISA-IEA sets; one for claims (837) and one for authorizations (278).

The 837P will be implemented in batch mode and processed as follows:

The submitting organization will send the 837P to IBC/KHPE through some means of communication. It will not remain connected while IBC/KHPE (Independence Blue Cross/Keystone Health Plan East) processes the transaction.

All X12 file submissions are evaluated upon receipt to determine if the ISA or IEA segments are unreadable or do not comply with the HIPAA Implementation Guide. If errors are found, IBC/KHPE will send a TA1 response transaction to notify the trading partner that the file cannot be processed. No TA1 response transaction will be sent for error-free files.

If the file submission passes the ISA/IEA pre-screening above, it is then checked for HIPAA compliance syntactical and content errors. When the compliance check is complete, a 997 will be sent to the trading partner informing them which claims in the file were accepted for processing or rejected.

The Unsolicited 277 acknowledgment is used for the 837P. The Unsolicited 277 acknowledgment provides accepted or rejected claim status for each claim contained within the batch.

We have come a long way and have gained a good understanding of healthcare EDI messages.

In the next blog we will look in to * 835: Electronic remittances messages in more detail. So do stay tuned.

e-Zest is a leading digital innovation partner for enterprises and technology companies that utilizes emerging technologies for creating engaging customers experiences. Being a customer-focused and technology-driven company, it always helps clients in crafting holistic business value for their software development efforts. It offers software development and consulting services for cloud computing, enterprise mobility, big data and analytics, user experience and digital commerce.