July 2015

Introduction to EDI
_________________________________________________________________________________________
What is EDI (Electronic Data Interchange)

Exchanging of business documents from one organization to another organization

in electronic format is called EDI. EDI replaces the faxing and mailing of paper
documents.

Why EDI

With EDI businesses will benefit with reduced cost, reduce errors, increase
processing speed and provide consistent results.

Because EDI documents will need to be processed by computers and not humans, a
standard data format needs to be used for exchanging data. This helps the
computer to locate specific data in specific location. Standard formats tells the
computer what each piece of information is and in what format. If a standard
format is not used, every company will send data in their company specific format
that will restrict the computer from understanding data.
Difference Between EDI and eFDE

 The purpose of the eFDE is key the claims in online.

 The purpose of the EDI is to key the claims by Electronic format .
 We can use duplicate membership to key the claim in eFDE where as in
EDI the membership should be a valid
 For giving multiples values like Multiple lines of information, Dx codes
and proc codes etc etc EDI is Flexible than eFDE
EDI Transactions:
 834 - Benefit Enrollment & Maintenance
 820 - Payments (Premium)
 270 - Eligibility Enquiry and Coverage
 271 - Response for Eligibility Enquiry and Coverage
 278 - Referral/ Certificate & License / Authorization
 837 - Claim
 NSF - Claim
 UB92 - Claim
 997 - Acknowledgment of Claim
 276 - Claim Status Enquiry
 277 - Claim Status Response
 835 - Electronic Remittance ( Claim Settlement )
 864 - Miscellaneous / Errors / Require More Information
EDI Elements
_________________________________________________________________________________________
A single EDI business document like a claim is called a Transaction Set (ST/SE).
Transaction set will contain a data elements, segments and an envelope.

Data elements
Segments
Envelopes

These elements are formatted as per the rules for that particular standard format
like ANSI X12.

When creating an EDI document it is necessary to strictly follow the rules of the
standard you are using. These rules define where to find what data and in what
format (Example - decimal, date etc). There is normally an EDI translator software
(Gentran and Mercator are two examples for ANSI X12 format) at the receiver end
that can convert the data into a user defined format. The standard format is
therefore every important to follow so the translator knows where to look for what
data.
EDI Data Element
_________________________________________________________________________________________
Data Element
A Data Element is the individual item of information in one transaction set. For
example – In every claim, you will find data elements such as City, State and Zip.
Every data element in EDI standard is defined by the type of data it represents.
Every data element will define

1. Data type – Numeric, Alpha Numeric, Date or time

2. Min and Max length of the data element.
3. Code value (if applicable). This determines what the next data element will
hold. Example – in the NM1 segment NM102 have a code value of ‘1’ or ‘2’
that tells if NM103 is a person or an organization.
EDI Segment
_________________________________________________________________________________________
Segment –

A segment in a EDI Transaction set is a group of identical data elements grouped

together. Example, Address will have Street Name, city, State and Zip. All these data
elements together is a segment. Every segment will begin with a segment ID
(example ST, NM1 etc) that describes the data element that follows. Each data
element is separated by a data element separator (usually ‘*’).

Every EDI standard documentation defines

1. Whether a segment is required or optional.

2. Whether a data element within a segment is required or optional.
3. The sequence of the segments and the data elements.
4. Number of times a segment can be repeated in a transaction set.
EDI Envelops
_________________________________________________________________________________________
Envelopes –

Just like how you use envelope to send letters, EDI also uses envelopes to house EDI
transactions. An EDI transaction can be categorized to have three envelops, a
message envelope, a group envelope and a Interchange envelope.

1. Each transaction set is placed in one message envelope(ST/SE).

2. A group of transaction sets are placed in a group envelope (GS/GE).
3. A group of envelopes sent from one sender to one receiver are placed in one
Interchange envelope (ISA/IEA).

Just like a regular envelope can hold multiple letters, an Interchange envelope can
hold multiple group envelopes and a Group envelope can hold multiple message
envelopes and a message envelope can hold multiple transaction set.
Basic structure of a 837 script:
ISA (Interchange Control Header)
GS (Functional Group Header)
ST (Transaction Set Header)
BHT (Beginning Of the Hierarchal Transaction)
1000 A (Submitter Loop)
1000 B (Receiver loop)
2000 A (Billing Provider Hierarchical level)
HL*01
2010 AA (Billing provider Name)
2000 B (Subscriber Hierarchical level)
HL*02
2010 BA (Subscriber Name)
2010 BB (Payer Name)
2000C (Patient Hierarchical level)
HL*03
2300 (Claim Information)
2400 (Service Line Information)
SE (Transaction Set Trailer)
GE (Functional Group Trailer)
IEA (Interchange Control Trailer)
Preparing and Transmitting an EDI file
_________________________________________________________________________________________
Transmitting an EDI document is a three step process.

1. Prepare the document

2. Convert the document to EDI X12 format.
3. Transmit the document

Step 1: Prepare the Document to be sent

The first step is to collect and organize the data. Instead of printing a
claim form the providers system can build an electronic file with the
necessary information to build the EDI X12 document. The usual
method of creating this electronic file will be human data entry into
screens.
Preparing and Transmitting an EDI file
_________________________________________________________________________________________
Step 2: Translate the documents to EDI format

This can be done either at the providers end where the provider can
purchase an EDI converter software that will convert the electronic
file into an EDI X12 file or the provider can use a Clearing House that
will take in the electronic file from the provider and convert the file
into an EDI X12 format file.

Step 3: Transmit the EDI X12 file to the Payer

After the files are converted to EDI X12 format, the provider can
directly transmit the files to the payer if they converted the file to EDI
X12 format internally or the Clearing house that converted the files to
EDI X12 format can transmit the files for them.

Clearing house is a trading partner that takes in claim information

from multiple providers, convert them to EDI X12 format and send
them to the Insurance company (payer). Clearing Houses work with
multiple providers and multiple payers.
Preparing and Transmitting an EDI file
_________________________________________________________________________________________
 EDI files transmitted by the provider or the trading partner comes to Wellpoint
through the Wellpoint FTP server.

 The files are delivered to an Enterprise Gateway Electronic Mail Box.

 A separate mail box is set up for each direct submitter (provider) and each
Trading partner contracted with Wellpoint.

 This is to help EDI keep a track of who delivered the files and where should the
response be sent to.
EDI Functionalities
_________________________________________________________________________________________
The claims that arrive in the Enterprise Gateway Electronic Mail Box will be
processed in the Enterprise EDI Clearinghouse. This is the name of the EDI
system in Wellpoint.

Five main functionalities of the Enterprise EDI Clearinghouse are

1. Commerce Manager
2. Route
3. Edit
4. Convert
5. Stage
EDI Functionalities
_________________________________________________________________________________________
Commerce Manager

EEDI Clearinghouse performs the following functions in Commerce Manager

 Perform Type 1 and Type 2 Syntax validation – Validates the 837 claims file as
per the instructions in the Implementation guide. File will be accepted if no
errors are found and will be rejected for non compliance of X12 data.

 Generate 999 responses – A 999 report is generated for both accepted and
rejected file. Sample below.

AK9 – A = Accept file/ R = Reject file/ P = Partially accepted.

EDI Functionalities
_________________________________________________________________________________________
Commerce Manager -

 Perform Type 1 and 2 Syntax Validation

 Generate 999 Responses
 Authenticate Trading Partner per transaction

Route –

 The majority of electronic claims are routed based on alpha prefix and
subscriber id (exceptions include GHI Medicare Crossover, Paper claims and VA
which are routed based on receiver id)

 As part of EDI processing, BDS (Business Distributor System) and EAPR

(Enterprise Alpha Prefix Router) are called to validate alpha prefixes and
membership and determine final claims routing.

 If membership does not exist on BDS, claim will be rejected and appear as FAIL
on 864 TX report (exception: VA system does their own membership
validation and returns a unique report)
EDI Functionalities
_________________________________________________________________________________________
Edit -

 Performs HIPPA and Business edits

 Creates Trading Partner response reports

Convert - The convert tool performs the following

 Convert 4010 to 5010 (if any)

 Convert X12 to proprietary format.
 Convert proprietary format to X12

Stage -

 300+ directories are maintained for staging.

 These directories are aligned to the back end receiving systems.
 Based on the routing results, claims are staged into the appropriate receiving
system directory.