EDI Introduction
EDI Introduction
EDI Introduction
Welcome to the EDI Overview. This lesson will help you understand EDI and the
common EDI health care transactions as they relate to your job.
We will be covering the following topics:
• Introduction to EDI
• Components of EDI
• EDI Communication & Transmission Methods
• EDI Business Analysis and Mapping
Each topic will present you with brief information and will be followed by a short scored
knowledge check. There will be a scored final assessment at the end. You must obtain
an overall passing score of 75% to receive credit for this course.
At any time during the course, you can use the navigation at the top or bottom to review
any topics.
At the end of this lesson you will be able to:
• Define EDI
• Identify the EDI transactions for the health care industry
• Label the various parts of an EDI transaction
• Decode the information in the EDI transactions
What is EDI?
Electronic data interchange (EDI) is a business-to- business, computer-to- computer
exchange of transaction information, such as Health Care Claims, Payments, and
Benefit Enrollment transactions.
EDI is compiled of standard Transaction Sets that are read by Translators by Trading
Partners.
EDI is communicated using standards established by a governing body.
In this course, we will only learn about health care EDI transactions.
EDI Communication
EDI data can be transmitted through any communications protocol agreed upon by the
trading partners such as Value Added Networks, SFTP, SCP, HTTPS and etc.
The graphic below summarizes how EDI is communicated and how it is different from
the manual methods.
Benefit Enrollment
834 – Benefit Enrollment and Maintenance
Eligibility Category
270 – Health Care Eligibility Benefit Inquiry
271 – Health Care Eligibility Response
Review
278 – Health Care Services Review and Response
Claim Type
837 – Health Care Claims – Institutional, Dental, Professional
Acknowledgement
999 - Acknowledgement
277 CA - Claim Acknowledgement
Claim Status
276 – Health care Claim Status Request
277 – Health Care Claim Status Response
Payment Order / Remittance Advice
820 – Payroll deducted and Other Group Premium Payment for Insurance
835 - Health Care Claim Payment/Advice
EDI standards are built on the concept of making electronic business documents
uniform, without regard to country or place of origin or industry.
They ensure document integrity. The standards provide the controls needed to track the
exchanged electronic business documents and confirm that all the data that was sent,
was in fact, received and processed by the trading partner.
EDI Standards
Role of HIPAA
Under the Health Insurance Portability and Accountability Act (HIPAA), health care
providers with a staff of 25 or more must submit claims using the ANSI ASC X12N and
NCPDP standard formats. Medicare mandates that all Medicare claims be submitted
using ANSI ASC X12N and NCPDP standard formats.
Technology has hitherto remained an under-used resource in the healthcare industry.
Until now, each area of work required personnel with the time and experience to work
with complex and time-intensive systems—including an average of 400 different
medical form ‘standards’.
This type of labor not only demands a large of amount of time and training, it also
creates an unacceptably high risk of problems arising from ‘human errors’.
EDI standards have the potential to revolutionize the way all aspects of the healthcare
industry function. The healthcare industry stands to gain from HIPAA, therefore, in time,
money and overall success.
Benefits of EDI
Speed
Data can move directly out of one computer system to another with almost no delay.
Data transmission happens in real time.
Accuracy
Errors are reduced because data is not being re-keyed.
Simplicity
EDI standards specify how data will be formatted and where it can be found. Since
everyone uses the same standards, it becomes simpler to transmit the data.
Security
Data is more secure. It is less likely to lose information transmitted through EDI than
information sent via mail. EDI can be accessed only by authorized users. Additionally,
there are audit trails and archives of data. Data sent though EDI methods cannot be
easily changed by unauthorized users. Neither is it subject to viruses.
Components of EDI
Software Components
Core
Translator
EDI Translators are software packages that convert the data in EDI transactions into a
human-readable format.
A Mapper gives instructions to the translator on how to convert the data to specifications
that make it human- readable.
At HEALTH CASE INDUSTRY, we use Websphere Message Broker (WMB and web
services).
Communications Tool
A communications management tool is used for sending and receiving trading partner
data.
This tool will typically support multiple transport protocols such as TCP/IP, FTP, HTTP,
SMTP, AS1, AS2 and ETC. Typically FTP and a script to connect to a Value Added
Network Service are included in the standard bundle of the communications component.
Since communication set ups can get complicated, sometimes it makes sense to use a
communications adapter that is outside of the EDI software package scope.
At HEALTH CASE INDUSTRY, we use Axway.
Scheduler
The scheduler automates operations in the EDI environment. It builds the steps to
automate the EDI process.
A scheduler can have trigger or event based processing features. For example, an EDI
translation and communications session may be instructed to kick off once a file arrives
in a certain directory.
At HEALTH CASE INDUSTRY, we use eGateway.
Additional
Database
A relational database management system is needed in order for the EDI software
package to function and store data.
This component is acquired separately from the EDI software package. Most software
vendors allow the flexibility of using any standard database tool such as Oracle,
MySQL, Microsoft SQL Server or Microsoft Access. Some EDI translators have their
own proprietary database.
At HEALTH CASE INDUSTRY, we use DB2/ODS.
Business Application
Once the machine-readable raw EDI data is translated, it is integrated into the business
application.
A business application can range from a small business package such as QuickBooks
to a full blown Enterprise Resource Planning (ERP) system such as SAP or PeopleSoft.
The business application may also be home-grown, as in the case of HEALTH CASE
INDUSTRY.
At HEALTH CASE INDUSTRY, we use BlueChip.
Integration Bridge
An integration bridge links the translated EDI file directly into the Business Application.
Business Applications typically do not allow proprietary translated files to be imported or
exported without doing some programming. For example, if a map converts an EDI X12
file to a comma delimited or CSV file, the integration bridge tool does the actual work of
importing the file into the business application.
At HEALTH CASE INDUSTRY, we use RTIS (Real Time Input System).
Hardware Components
The main hardware components of an EDI environment are:
Operating System
Most EDI software packages support multiple operating systems (OS). The most
popular environments are:
• A Microsoft environment with Windows Servers, network stations and Microsoft
SQL Server databases
Or
• A UNIX environment and IBM based mainframes such as the AS/400 and MVS
with an ORACLE database as a back-end
Networking
Typically an EDI server is in a data center facility with appropriate network infrastructure
in place to support the required EDI communication methods. Network routers and
switches help direct the path for data travel. Firewalls, VPN gateways and intrusion
detection systems ensure the data is secure. Data centers can be in-house or co-
located depending on the business’ needs.
People
DI teams may include the following:
• Mapper
• Coordinator
• Developer
• Operations people
The following departments from the organization may be involved in managing EDI:
• Admissions
• Billing
• Adjudication
• HR
EDI Communication
Most EDI data is now transmitted via high speed broadband internet through fiber optic
cables.
Clearing houses are third party service providers that translate non-EDI data to EDI
data.
They can also translate EDI to EDI by taking the received raw data, massaging it,
scrubbing it and migrating it to another document.
Clearinghouses can also convert paper documents to EDI and vice versa.
Benefits of Clearing Houses
• Faster reimbursement
• Reduction in rejected claims (Clean Claims)
• Decrease in time-intensive manual tasks
• Increase in productivity and efficiency
• Improvement in cash flow
Value Added Network (VAN)
A Value Added Network (VAN) is a third party intermediary network between trading
partners. They forward EDI data.
While Clearing Houses can translate non-EDI data to EDI data, VANs only move EDI
data. They do not translate raw data to EDI.
VANs assign a mailbox to the various trading partners. The translated EDI data is
uploaded to the VAN mailbox for distribution to other trading partners.
Benefits
• Single point one-stop shop for sending and receiving EDI data.
• Support for Multiple Protocols
• Compliance Checking
VAN providers can validate the EDI data at the envelope level.
• Various Routing Options
For example, copying a duplicate copy of the EDI transaction to additional
recipients
• Dispute Resolution
Since VAN providers serve as a third party between trading partners, the
trading partner can use transmission logs to determine if mission critical data
was actually transmitted.
• Support
Most VAN providers monitor EDI traffic and provide support 24/7.
EDI Transmission
FTP
FTP or File transfer Protocol is an extremely popular method used for transmitting data
directly.
SSH or Secure Shell (also known aa SFTP, Secure File Transfer Protocol) is a security
protocol for logging onto a remote server.
The benefit of using SFTP is that the whole transmission is encrypted, including the
user ID.
Trading partners set up a regular FTP connection (typically on port 21) and encrypt the
data using PGP keys. Often with PGP, the data is also digitally signed.
VPN (Virtual Private Network)
Some companies chose to FTP over a VPN. Sending data through the VPN includes
the process of encrypting or randomizing the traffic over the Internet so that a third party
cannot intercept and make sense of the communication.
VPNs are typically more expensive to set up than SFTP or FTP with PGP.
EDI over the Internet is a fairly recent method. Three standard protocols are used:
• Applicability Statement (AS1) via SMTP
Now that you have some understanding of what EDI is and its benefits as well as the
commonly used EDI transactions in the health care industry, let's understand how to
read these EDI transactions.
If you need, please review the EDI transactions used in the health care industry. We
talked about these in the topic titled Introduction to EDI. Use the drop-down menu at
the top to navigate to that section.
EDI Envelopes
Just as paper documents are sent in envelopes and it is possible to mail many
documents in a single envelope, EDI documents are exchanged using several
envelopes.
3. Interchange Envelope
All group envelopes being sent from one sender to one receiver are placed in an
Interchange envelope.
EDI Terms
Segments
Segments are what make up an EDI document. Segments consist of data elements that
are logically related.
Segment Terminators
These are the special characters appearing at the end of a segment to indicate the
termination of the segment.
Sometimes, you cannot see them, for example, the carriage-return-line-feed is not
visible to the human eye, but it does exist.
Sometimes they are visible. The tilde character (~) separates the HL and PRV
segments in this example: HL*1**20*1~PRV*BI*PXC*207Q00000X
Data Elements
The data element is the smallest item in the EDI data. It is similar to a field in a
database. The elements contain the actual data. They consist of qualifiers and values.
Example: HL*1**20*1~PRV*BI*PXC*207Q00000X
The segments in the above example are red bold and the data elements are in italics.
Element Delimiter
The data element delimiter is a special character that separates the data elements.
In the example above, the element delimiter is an asterisk character.
Qualifiers
Qualifiers are sometimes used to indicate the values in the data elements.
Example 1: DTP*472*D8*20081121~
DTP-01 = 472 means “Service Date”
DTP-02 element is the Date Time Period Format Qualifier, where ‘D8’ means "Date
Expressed in Format CCYYMMDD"
Example 2: DTP*472*RD8*20081121-20091122~
DTP-02 = RD8 means “Range of Dates Expressed in Format CCYYMMDD-
CCYYMMDD”.
There are more than 100 qualifiers available in the EDI standards just for the date and
time segments. Using qualifiers eliminates the need to have dedicated fields. For
example, CLM- 02 is the Claim Charge Amount. CLM-02 does not need a qualifier.
Composite Data Elements
They are a set of sub-elements that represent a single named item. Think of them as a
set of child elements of a regular data element.
For example the SVC segment has seven regular elements and two composite (sub-
elements) elements. SVC01 and SVC06 have sub-elements.
The regular element separator separates SVC01, SVC02, SVC03, SVC04, SVC05,
SVC06, SVC07 and the sub-element separator separates the sub-elements in SVC01
and SVC06.
In the example below the element separator is an asterisk * the sub-element separator
is a colon: (defined in ISA-16 element), and segment the Terminator is "~", the SVC
segment can look like this (only using SVC01-01 and SVC01-02 in the example):
SVC*HC:99214*600*340 ~
In the second example below, STC01 is F2, which has a sub-element of 107. F2 means
that the claim was finalized with a denial. The code for denial is 107.
STC*F2:107*20121203**499*0*20121203~
EDI Guides
1. The EDI Fundamentals and Best Practices Guide that explains all the health care
transactions.
2. The ANSI X12 Manual, which contains standards for using the EDI Transactions.
EDI Transactions
Next, let's understand the structure of each of these transactions and learn how to read
the data in them.
Start with transactions 270, 271 to learn about all the elements in these transactions.
The 270 transaction requests eligibility and benefit information from the Insurance
Company of the patient from a Provider of Service.
The 271 transaction responds to the eligibility and benefit information of the patient set
to receive care, from the Insurance Company to the Provider of Service.
Each line is referred to as a segment. It starts with a code that tells you something
about the information on that line.
Each segment also has a matching pair item that marks the end of that level of
information. Click the button below to see the matching pairs.
Within each segment, various kinds of information appear, each separated by an
asterisk or other identifier.
These are called elements. They are common across all EDI transactions.
EDI Transaction 270 Identifiers
In discussing EDI information, we refer to a particular line by its letter/number name and
then to the specific position within that line.
In the example, the ISA segment 1-4 is indicated by the red highlight box. The
segment’s element positions 1 through 4 are indicated by the red highlight box.
Each position, including spaces, both indicated by the red highlight boxes is a data
element separated a delimiter, the asterisk (*) character.
A colon (:) at the end of the segment is a Sub- Element Separator, which means that
additional data elements of the same segment follow.
End of the segment is denoted by the tilde (~).
Let’s understand each of the segments in this sample transaction.
This is the outermost envelope. All of the EDI data is placed within this layer.
The purpose of this segment is to identify the sender and receiver, date, time and
control number information.
In the example here ISA-07 has a qualifier of 01 which identified the next segment (ISA-
8) as DUNS Number.
ISA-08 shows the DUNS number.
ISA-09 and ISA-10
ISA-09 is the interchange date in YYMMDD format.
ISA-10 is the time in HHMM format.
In the example above this transmission was sent on January, 1st 2012 at 07:42.
ISA-11
For EDI Versions 00402 and greater this will serve as a repetition separator used to
separate repeated occurrences of a simple data element or a composite data structure.
For example a pipe character (I) or a carrot (^) like in our example here can be used in
this field.
There are EDI versions that are represented in the header segment. The concept of EDI
versions is explained in ISA-12.
ISA-12
This is the EDI standard published version number. In the example here it is 00501.
ISA-13
This is a 9 digit control number used for tracking purposes. This number must match
IEA-02 (Interchange Envelope Trailer).
This number should be unique and should not be re-used for at least 3 years.
ISA-14
This is the acknowledgement request indicator. It is used mainly for reporting the status
of processing a received interchange header and trailer or the non-delivery by a network
provider.
While usually this will be set to ‘0’ value, some payers send these back as part of their
acknowledgement process.
This is hardly ever used and should not be confused with the 997 acknowledgement
document.
ISA-15
This indicates whether data enclosed by this interchange envelope is test ‘T’, production
‘P’ or information ‘I’. In the example above it is ‘P’.
ISA-16
This field provides the delimiter used to separate component data elements within a
composite data structure.
This value must be different than the data element separator and the segment
terminator.
In the example above the value is the "colon" (:). However, it can also be any valid
ASCII special character. This is also referred to as the Sub-Element Separator.
Functional Group Header (GS)
This is the second segment of all EDI transactions.
The purpose of this segment is to be able to group similar transactions in an
interchange envelope.
In the example here, there is only one type of transaction, HS, but, if there was also
another transaction, such as a ‘999’ Implementation Acknowledgement, it would be
grouped under its own group with GS*FA.
GS-01
In the example above, GS01 represents ‘HS’ for Eligibility, Coverage or Benefit Inquiry
as the functional identifier code.
That means all the documents between the GS and the GE segment will be grouped as
claims. Some other examples of other GS01 entries could be ‘HP’ for Health Care
Payment and ‘BE’ for Benefit Enrollment and Maintenance.
GS-02
This ID will typically be the same as ISA-06; however, some companies chose to create
a unique ID in GS02, for example, to separate different business divisions.
GS-03
GS05 is the time the transaction was transmitted expressed as HHMM. Typically the
dates and times will match the ISA segment.
GS-06
This number should be unique and should not be re-used for at least 3 years. This
number is different from the ISA control number in ISA-13.
GS-07
Positions 1-6 005010 represent the ASC X 12 Procedures Review Board publications.
ST- 01
In the example above the transaction set is a 270, which represents an Eligibility,
Coverage or Benefit Inquiry.
There are more than 300 transaction types in the EDI X12 standards. They all start with
this ST segment.
ST- 02
This is a control number that makes the ST - SE relationship unique. It must always be
unique.
Usually this number will be sequential. This control number must match the SE-02
element.
ST- 03
Some translators do not allow mapping to ISA and GS segments. This element will
allow a user to map to the version number (e.g. 005010X222A1) if needed. The ST-03
will always take precedence over GS08.
Trailer Segments
After the data segments, come the trailer segments.
The first trailer segment is the Transaction Set Trailer.
Transaction Set Trailer (SE)
SE- 01
This is the segment count of all the segments (including ST/SE) between ST and SE
segments.
This is used as a control method to validate that no data is missing. If the count is
incorrect, most translators will reject translating such a document.
SE- 02
This is a control number that makes the ST-SE relationship unique.
It must always be unique. Usually this number will be sequential. This control number
must match the ST-02 segment.
The functional group trailer GE indicates the end of the functional group.
Even though, in the example there is only one GS-GE group, there can be multiple GS -
GE groups in a single ISA envelope.
GE-01
GE-01 is the total number of transactions included in the document. In the example
there are two 270 transactions therefore, GE-01 = 2.
GE-02
GE-02 is the group control number and must match GS-06.
This is the outermost envelope trailer. All of the EDI data is placed within this ISA-IEA
layer.
IEA-01
IEA-01 has the total count of Functional Groups (GS-GE).
IEA-02
IEA-02 is the control number and it should match ISA-13.
Transaction 270 Data Segments
Between the ST and SE segments are the data segments.
In this transaction, there are two ST- SE segments.
Let's learn about the various segments in this transaction, which shows a standard
eligibility request sent from a Provider of Service to an Insurance Company.
The Provider of Service, UCLA Medical Center, has submitted a batch of 270
Requests, containing two patients Mickey Mouse and Donald Duck who happened to
be the subscribers as well, directly to the Insurance Company, BCBS Disney.
Data Segment: Beginning of Hierarchical Transaction (BHT)
The information in this segment is arranged in the following order:
Information Source, Information Receiver, Subscriber, Dependent
This order is called the Hierarchical Structure Code.
Click each of the elements of this segment in the red highlighted area in the image here
to learn more.
Transaction 271
The 271 transaction responds to the eligibility and benefit information of the patient set
to receive care, from the Insurance Company to the Service Provider.
In response to the transaction 270 we saw earlier, the Insurance Company returned a
271 Response directly to the Service Provider with the eligibility details requested.
In this example, the Insurance Company has only included one response to the Service
Provider batch.
This practice allows a Service Provider to receive valid 271 Responses in a timely
manner in the event there is difficultly verifying one of many 270 Requests.
All 271 Responses will be returned to the Service Provider as they have been
processed and validated.
1. Interchange Envelope
This is the beginning segment of almost all EDI transactions. It is the outermost
envelope. All of the EDI data is placed within this layer. The purpose of this segment
is to identify the sender and receiver, date, time and control number information.
2. Function Group Envelope
This is the second segment of all EDI transactions. The purpose of this segment is
to be able to group similar transactions in an interchange envelope.
3. Transaction Set Envelopes
This is the third segment of all EDI transactions. It identifies the transaction type and
assigns a control number to the transaction.
What are EDI Data Segments
In between the opening and closing transaction segments are the EDI data segments.
Special characters appear at the end of a segment to indicate the termination of the
segment. They can be visible characters such as a tilde (~) or invisible, such as a
carriage return.