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.

Heath Care EDI Transactions

Listed below are the health care EDI transactions.

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

ASC X12 Standards, DISA and X12 N

ASC X12 is the most widely used EDI standard in the United States.
The American National Standards Institute ANSI (founded 1918), started the work of
creating the EDI standards in 1979.
It authorized the X 12 Accredited Standards Committee (ASC X12) to develop these
standards. Data Interchange Standards Association (DISA), the administrative office of
ASC X 12, provides technical and administrative support for EDI.
ASC X12 standards contain over 300 transactions. There are several subsets of
transactions specific to various industries. The Insurance Industry uses the X12 N
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.

In its raw form, EDI data is very difficult to read manually.

At HEALTH CASE INDUSTRY, we use Edifacs and WTX (Websphere Translator

Extender).
Mapper

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.

Fail Over, Back up & Disaster Recovery

Fail over is the method to become operational again, if for example, the hard disk or the
CPU motherboard of the EDI server crashes. The speed at which the EDI environment
needs to become operational again will dictate the type of fail over requirements.
Back up: All EDI data formats should be backed up. This includes the machine-
readable EDI data, the translated proprietary data, communication logs and the
database.
Disaster Recover (DR): In case of any disasters, natural or man-made, that damage a
data center, a well-implemented disaster recovery plan should be in place.
At HEALTH CASE INDUSTRY we use https and Messaging & Queuing (MQ)

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.

At HEALTH CASE INDUSTRY, we communicate EDI transactions through Axway.

Click the methods below to learn more.
Clearing House

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

In order to be able to send and receive EDI documents a method of electronic

communication must exist and must be secure.

Click on the common methods for EDI Transmission to learn more.

At HEALTH CASE INDUSTRY we use EDIINT. If EDIINT is not available then SFTP or
FTP is used.

FTP
FTP or File transfer Protocol is an extremely popular method used for transmitting data
directly.

SFTP over SSH

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.

FTP with PGP

Another method of securing an FTP transmission is by using PGP or Pretty Good
Protection.

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 (EDIINT): AS1, AS2, AS3

EDI over the Internet is a fairly recent method. Three standard protocols are used:
• Applicability Statement (AS1) via SMTP

• AS2 via HTTP - This is the most popular currently

• AS3 via FTP

EDI Business Analysis and Mapping

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.

EDI document transmission uses a system of three “envelopes” to house transaction

sets.

1. Transaction Set Envelopes

Each transaction set is placed in its individual envelope.

2. Function Group Envelope

A group of transactions sets, for example, a group of claims is placed in a group
envelope.

3. Interchange Envelope
All group envelopes being sent from one sender to one receiver are placed in an
Interchange envelope.

Below is an example transaction and to its right is an illustration of the enveloping

structure.
• The red arrows indicate the Interchange Envelope.
• The blue arrows show the Function Group Envelope.
• The green arrows display the beginning and ending of Transaction Sets. Note that
there can be more than one Transaction Set. However, there is only one
Interchange and Function Group Envelope set.
• In between the Transaction Sets are the Data Segments.

EDI Terms

Segments
Segments are what make up an EDI document. Segments consist of data elements that
are logically related.

Example of Claim segment: CLM*ABC7001*145.5***11:B:1*Y*A*Y*Y

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

You have two resources available to you:

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.

EDI Transaction 270, 271

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.

Let's understand the key identifiers in the 270 transaction here.

EDI Transaction Identifiers

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.

Interchange Control Header (ISA)

This is the beginning segment of almost all EDI transactions.

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.

There are 16 elements in this segment.

This segment must match the
Internet Envelope Trailer IEA trailer segment.

ISA-01 through ISA-04

In the example here, ISA-01 through ISA-04 are not being used.
These elements are hardly ever used anymore. That is why they are 00 and null.
They served authorization and security password purposes in the past.

ISA-05 and ISA-06

These segments represent the sender qualifier and the sender ID.
In the example here ISA-05 has a qualifier of 12 which means the phone number and
ISA-06 has the actual phone number.

ISA-07 and ISA-08

These segments represent the receiver qualifier and the receiver ID.

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 is the sender’s ID.

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

This is the receiver’s ID.

This ID will typically be the same as ISA-08, though some companies choose to create
a unique ID in GS03. This might be done to identify different business divisions, as in
this example.

GS-04 and GS-05

GS04 is the date the transaction was transmitted expressed as CCYYMMDD.

GS05 is the time the transaction was transmitted expressed as HHMM. Typically the
dates and times will match the ISA segment.

GS-06

This is the group control number and must match GE-02.

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

This is the EDI standards agency, X stands for X12.

GS-08

This is the EDI version “005010X279A1.”

Positions 1-6 005010 represent the ASC X 12 Procedures Review Board publications.

Positions 7-13 X279A1 represent industry and trade association identifiers.

In EDI shorthand this is referred to as the “50-10” release.

Transaction Set Header (ST)

This is the third segment of all EDI transactions.
It identifies the transaction type and assigns a control number to the transaction.

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

This is a reference assigned to identify implementation convention (similar to Version

Number in GS08).

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)

In this transaction there are two ST-SE segments.

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.

Functional Group Trailer (GE)

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.

Interchange Group Trailer (IEA)

This is the last segment of all EDI documents.

This is the outermost envelope trailer. All of the EDI data is placed within this ISA-IEA
layer.

This segment must match the ISA trailer element.

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.

Data Segment: Hierchical Level (HL)

There are three HL segments in each of the ST-SE segments here.
Each HL segment in the red highlighted area to learn about them
Data Segment: Individual or Organization Name (NM1)
In this segment the organization is the insurance company.
Click each of the elements of this segment in the red highlighted area in the image here
to learn more.
Data Segment: Individual or Organization Name (NM1)
In this segment the organization is the service provider.
Click each of the elements of this segment in the red highlighted area in the image here
to learn more.
Data Segment: Trace

Data Segment: Individual or Organization Name (NM1)

In this segment the individual is the member.

Data Segment: Demographics (DMG)

Data Segment: Eligibility or Benefit Inquiry (EQ)

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.

Let's understand each of the data segments in this transaction.

Transaction 271 Data Segment: BHT

Beginning of Hierarchical Transaction: BHT*0022*11*776655432*20120124*07495100
Hierarchical Structure Code : Information Source, Information Receiver, Subscriber,
Dependent
Transaction Set Purpose Code : Response
Reference Identification : 776655432
Date : 1/24/2012
Time : 7:49:51 AM
Transaction 271 Data Segment: NM1: Subscriber
Individual or Organizational Name:
NM1*PR*2*BCBS DISNEY*****PI*8584537845
Entity Identifier Code : Payer
Entity Type Qualifier : Non-Person Entity
Name Last or Organization Name : BCBS DISNEY
Identification Code Qualifier : Payor Identification
Identification Code : 8584537845

Transaction 271 Data Segment: NM1: Service Provider

Individual or Organizational Name: NM1*80*2*UCLA MEDICAL
CENTER*****XX*1215193883
Entity Identifier Code : Hospital
Entity Type Qualifier : Non-Person Entity
Name Last or Organization Name : UCLA MEDICAL CENTER
Identification Code Qualifier : Centers for Medicare and Medicaid Services National
Provider Identifier
Identification Code : 1215193883
Transaction 271 Data Segment: Trace
Trace: TRN*1*11230*9621162462
Trace Type Code : Current Transaction Trace Numbers
Reference Identification : 11230
Originating Company Identifier : 9621162462

Transaction 271 Data Segment: NM1: Subscriber 2

Individual or Organizational Name: NM1*IL*1*MOUSE*MICKEY****MI*60345914A
Entity Identifier Code : Insured or Subscriber
Entity Type Qualifier : Person
Name Last or Organization Name : MOUSE
Name First : MICKEY
Identification Code Qualifier : Member Identification Number
Identification Code : 60345914A
Transaction 271 Data Segment: DMG
Demographic Information: DMG*D8*19281118*M
Date Time Period Format Qualifier : Date Expressed in Format CCYYMMDD
Date Time Period : 19281118
Gender Code : Male

Transaction 271 Data Segment: DTP

Date or Time or Period: DTP*346*D8*20120107
Date/Time Qualifier : Plan Begin
Date Time Period Format Qualifier : Date Expressed in Format CCYYMMDD
Date Time Period : 20120107

Transaction 271 Data Segment: EB

Eligibility or Benefit Information:
EB*1*FAM*30*PR*BCBS DISNEY PPO A
Eligibility or Benefit Information Code : Active Coverage
Coverage Level Code : Family
Service Type Code : Health Benefit Plan Coverage
Insurance Type Code : Preferred Provider Organization (PPO)
Plan Coverage Description : BCBS DISNEY PPO A
Transaction 271 Data Segment: EB
Eligibility or Benefit Information: EB*B**98***27*5
Eligibility or Benefit Information Code : Co-Payment
Service Type Code : Professional (Physician) Visit - Office
Time Period Qualifier : Visit
Monetary Amount : 5

Transaction 271 Data Segment: DTP 2

Date or Time or Period: DTP*356*D8*20120107
Date/Time Qualifier : Eligibility Begin
Date Time Period Format Qualifier : Date Expressed in Format CCYYMMDD
Date Time Period : 20120107
Transaction 271 Data Segment: DTP 3
Date or Time or Period: DTP*357*D8*20150107
Date/Time Qualifier : Eligibility End
Date Time Period Format Qualifier : Date Expressed in Format CCYYMMDD
Date Time Period : 20150107

Transaction 271: Other Scenarios

You can read about additional situations in which transactions 270 and 271 are used in
the EDI Fundamentals and Best Practices guide that you can find on FYIBlue.
You can find this guide by searching for the keywords ANSI, then clicking on the ANSI
5010 Background link. At the bottom of the ANSI 5010 Background page, you will find
the EDI Academy Training Guide titled Fundamentals and Best Practices.
This completes the overview about information common across all EDI health care
transactions and EDI transactions 270, 271. Let's review.
EDI Transactions 270, 271 Review

What are EDI Envelopes

EDI document transmission uses a system of three “envelopes” to house transaction
sets. Each envelope has an opening and closing segment.

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.

What are EDI Segments

Each line in all EDI transactions 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.

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.

What are EDI Elements

Within each segment, various kinds of information appear, each separated by an
asterisk or other identifier. These are called elements. Characters such as the asterisk
(*) that separate the data elements are called data element delimiters.

What are Qualifiers

Qualifiers are used to indicate the values in the data elements.

For Example: DTP*472*D8*20081121~

DTP-01 = 472 means “Service Date”
What are transactions 270 and 271 used for?
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.