EDI 270–5010 Documentation - ISA – Interchange Control Header

 

            

ISA – Interchange Control Header  

The ISA is a fixed record length segment and all positions within each of the data elements must be filled. The first element separator defines the  element separator to be used through the entire interchange. The segment terminator used after the ISA defines the segment terminator to be used throughout the entire interchange.This results in the segment terminator always being in position 106.


PMS Product Reference

image


  Seg ID Segment Name Format Length Ref# Req Value
Header ISA Interchange Control Header 3 R ISA
Element Separator AN 1 *
ISA01 Authorization information qualifier ID 2/2 101 R 00 or 03 See below for more information
Element Separator AN 1 *
  ISA02 Authorization information AN 10/10 102 R Will contain User ID if ISA01 is 03.
Will Contain 10 Empty spaces if ISA01 is 00
    Element Separator AN 1     *
  ISA03 Security information qualifier ID 2/2 103 R Will Contain 01 if ISA01 is 03.
Will Contain 00 if ISA01 Is 00.
    Element Separator AN 1     *
  ISA04 Security information AN 10/10 104 R Will contain Password if ISA01 is 03.
Will Contain 10 Empty spaces if ISA01 is 00
    Element Separator AN 1     *
  ISA05 Interchange ID Qualifier ID 2/2 105 R ZZ
    Element Separator AN 1     *
  ISA06 Interchange Sender ID AN 2/15 106 R See below for more information
    Element Separator AN 1     *
  ISA07 Interchange ID Qualifier ID 2/2 105 R 01
    Element Separator AN 1     *
  ISA08 Interchange Receiver ID AN 15/15 107 R See below for more information
    Element Separator AN 1     *
  ISA10 Interchange Time TM 4/4 109 R Current Time in HHMM Format
    Element Separator AN 1     *
  ISA11 Repetition Separator ID 1/1 110 R ^
    Element Separator AN 1     *
  ISA12 Interchange Control Version Number ID 5/5 111 R 00501
    Element Separator AN 1     *
  ISA13 Interchange Control Number NO 9/9 112 R 000000001 (See below for more info)
    Element Separator AN 1     *
  ISA14 Acknowledgement required          
    Element Separator AN 1     *
  ISA15 Usage indicator ID 1/1 114 R P or T (See below for more details)
    Element Separator AN 1     *
  ISA16 Component Element Separator   1/1 115 R : (semi colon). this value must be different than the data element separator and the segment terminator
    Element Separator AN 1     *
               

Sample:  

ISA*00*          *00*          *ZZ*8431           *ZZ*ZIRMED         *130215*1234*^*00501*000000001*1*P*:~


Important Note on the above sample:
ISA02
Since ISA is fixed length segment, even though if no values are present, we need to fill up empty spaces. Here ISA02 is filled with 10 empty spaces.

ISA04
Since ISA is fixed length segment, even though if no values are present, we need to fill up empty spaces. Here ISA04 is filled with 10 empty spaces.

ISA06
Since ISA is fixed length segment, if the value is not 15 characters length, then we need to append empty space to make 15 characters string.

ISA08
Since ISA is fixed length segment, if the value is not 15 characters length, then we need to append empty space to make 15 characters string.


Segment Structure  

image



Sample 2
ISA*03*id27032743*01*XYXY2233  *ZZ*XX09211223     *01*030240928      *130829*1102*^*00501*290811021*0*T*:~

User Name and Password
In some clearing house, they might ask to send the user name and password along with each EDI file. That's what Authorization information Information refer ISA01, ISA02,ISA03 and ISA04.  After you sign up with the clearing house, ask your user name and password to send along the EDI File if they need.  In such case, ISA01 will have the value"03" , ISA02 will have the user id, ISA03 will have the value "01" and ISA04 will have the actual password. Very important, since ISA is fixed length segment, and ISA02 is 10 character, so if your user id is less than 10 characters, then you need to append empty spaces to make it as 10 character word.
 
Sample with the User id and Password.

 

Segment Structure  
image



ISA01 - Authorization Information Qualifier
Code to identify the type of information in the Authorization Information
Code Definition
00 No Authorization information Present(No Meaningful information in 102). Advised unless security requirements Mandate use of Additional identification information.
03 Additional Data Identification.

 


ISA03 - Security Information Qualifier
Code to identify the type of information in the Security information qualifier

Code Definition
00 No Security information Present(No Meaningful information in 104). Advised unless security requirements Mandate use of password data.
01 Password

 

ISA05, ISA07- Interchange ID Qualifier
Code to identify the type of information in the Security information qualifier

Code Definition
01 Duns(Dun & BradStreet)
14 Duns Plus Suffix
20 Health Industry Number (HIN)
27 Carrier Identification Number
28 Fiscal Intermediary Identification Number.
29 Medicare Provider and Supplier Identification Number
30 U.S Federal Tax Identification Number
33 National Association Of Insurance Commissioners Company Code (NAIC)
ZZ Mutually Defined



ISA06 – Interchange Sender ID
During the sign up process with clearing house, they will assign a unique ID to the software vendor. So in the practice information setup, software should have a option to enter this value. This is mandatory for all the EDI Files, without this ID, clearing house will not be able to process the file.

ISA08 – Interchange Receiver ID
During the sign up process with clearing house, they will provide this value. Usually, this will be clearing house name. So in the practice information setup, software should have a option to enter this value. This is mandatory for all the EDI Files, without this ID, clearing house will not be able to process the file.

ISA13 – Interchange Control Number
Control Number assigned by the Sender for tracking purpose. This number must be identical to the Interchange Trailer IEA02. Ever time
when creating the EDI File, software can generate a unique number to identify the batch for later case to track. 

ISA14 - Acknowledgment Requested.


Code Definition
0 No Acknowledgment Requested
1 Interchange Acknowledgement Requested

Default to 0. In some cases, if the software vendor integrated to clearing house via web services. then we can ask the clearing house to send the acknowledgment for each EDI File batches.

ISA15 – Usage Indicator.

Code Definition
P Production Data
T Test Data

After the  sign up process with clearing house, they will ask the software vendor to send sample files with different use cases. In such cases, all the files should be send as Test Data. So in the practice information setup, software should have this option to select. Once test files are approved, then software admin can change this value to Production.

 

            



Questions or feedback are always welcome.


EDI 270 - 5010 Health Care Eligibility/Benefit Inquiry


If you are new to Medical Billing, then please read this article first.

If you are new to EDI, then  read the following articles

1.
What is an EDI ?
2. EDI Transactions 

3. Understanding EDI Structure
4. EDI Instruction

Introduction

For the health care industry to achieve the potential administrative cost savings with Electronic Data Interchange (EDI), standards have been developed and need to be implemented consistently by all organizations. To facilitate a smooth transition into the EDI environment, uniform implementation is critical.
Providers of medical services must currently submit health care eligibility and benefit inquiries in a variety of methods, either on paper, via phone, or electronically. The information requirements vary depending upon:

  • type of insurance plan
  • type of service performed
  • where the service is performed
  • where the inquiry is initiated
  • where the inquiry is sent

  • The Health Care Coverage, Eligibility, and Benefit transactions are designed so that inquiry submitters (information receivers) can determine (a) whether an information source organization (e.g., payer, employer, HMO) has a particular subscriber or dependent on file, and (b) the health care eligibility and/or benefit information about that subscriber and/or dependent(s). The data available through these transaction sets is used to verify an individual’s eligibility and benefits, but cannot provide a history of benefit use.
    The purpose of this implementation guide is to explain the developers’ intent when the Health Care Eligibility, Coverage, or Benefit Inquiry (270) and Health Care Eligibility, Coverage, or Benefit Information (271) transaction sets were designed and to give guidance on how they should be implemented in the health care industry. Specifically, this guide defines where data is put and when it is included for the ANSI ASC X12.281 and X12.282 transaction sets for the purpose of conveying health care eligibility and benefit information.

    This paired transaction set is comprised of two transactions: the 270, which is used to request (inquire) information, and the 271, which is used to respond with coverage, eligibility, and benefit information. The official names for these transactions are:

    ANSI ASC X12.281 - Eligibility, Coverage, or Benefit Inquiry (270)
    ANSI ASC X12.282 - Eligibility, Coverage, or Benefit Information (271)


    The 270 document typically includes the following:

  • Details of the sender of the inquiry (name and contact information of the information receiver)
  • Name of the recipient of the inquiry (the information source)
  • Details of the plan subscriber about to the inquiry is referring
  • Description of eligibility or benefit information requested

  • The ASC X12N Specification  - 5010 Version

     1. EDI 270–5010 Documentation - ISA – Interchange Control Header
     2. EDI 270–5010 Documentation – GS – Functional Group Header
     3. EDI 270–5010 Documentation – ST – Transaction Set Header
     4. EDI 270–5010 Documentation – BHT – Beginning Of Hierarchical Transaction
     5 EDI 270–5010 Documentation – HL – Hierarchical Level
     6. EDI 270–5010 Documentation–2100A Information Source Name
     7. EDI 270–5010 Documentation–2000B Information Receiver Level
     8. EDI 270–5010 Documentation–2000B Information Receiver Name
     9. EDI 270 – 5010 Documentation-2000C Hierarchical Level
    10. EDI 270 – 5010 Documentation – Subscriber Trace Number
    11. EDI 270 – 5010 Documentation –  2100C SUBSCRIBER Name

    EDI   Examples

    Please note ; all these examples are tested against WPC First Pass software.

    You can download trial version here.

    Also, you can download the following trial version software to view/validate EDI File.

    1. EDI Notepad
    2. HIPPA Document Viewer 2
    3. On Line Validator American Coders
    4. On Line Validator EDIVance

    The following open source converts X12 EDI File to XML and 1500.
    OopFactory X12 Parser

    The following URL discuss about other open source in EDI Software.
    Comparing Open Source EDI Software

    Sample EDI 270 5010. For clear understanding, line separator are used between loops

    ISA*03*id27032743*01*XYXY2233  *ZZ*XX09211223     *01*030240928      *130829*1102*^*00501*290811021*0*T*:~
    GS*HS*XX09211223*030240928*20130829*1102*1*X*005010X279A1~
    ST*270*0001*005010X279A1~
    BHT*0022*13*0001*20130829*1102~
    HL*1**20*1~
    NM1*PR*2*FLORIDA BLUE*****PI*BCBSF~
    HL*2*1*21*1~
    NM1*1P*2*Bella Vista Health Center*****XX*1306849724~
    HL*3*2*22*0~
    TRN*1*290811021*3030240928~
    NM1*IL*1*MULLIN*DANIEL****MI*XJBH12345678~
    DMG*D8*19571112~
    DTP*291*D8*20130829~
    EQ*30~
    SE*13*0001~
    GE*1*1~
    IEA*1*290811021~


    Questions or feedback are always welcome. You can email me at
    vbsenthilinnet@gmail.com.  

    RESTful Java Web Services wrote in java which takes JSON File as input and gives you the actual EDI Message.

    Demo

     
    In your EMR/PMS software, if you need to parse the EDI 271 Response, You can use our API Service which will parse and returns as Human Readable Text. Please contact me via email vbsenthilinnet@gmail.com  for more details

    I’ve developed Web API in which you can pass the EDI 271 Message and API will return the Human Readable Text.

    These RESTful Web Services are developed using Spring Boot.

    The following video demo explain how to Make restful web service API for the service.

    Parse 271 Message to Text

    Enter video caption here



    In order to test all the RESTful Web Services , an testing tool also developed and here is the video demo for the same.

    Parse EDI 271


    Parse 271 Message to JSON Format

    Enter video caption here

    Parse 271 Message to HTML
    Parse 271 Message to HTML



    Workflow

    1) Patient Books an appointment.
    2) Billing team before the appointment date, check the Patient Insurance Eligibility.
    3) Software prepares the EDI 270 Message and send to the Payer via Clearing House entity, Payer in turn returns the Response in EDI 271 Message.  Here clearing house is the middle man between Health care Organization and Payer
    4) Software parse EDI 271 Message  and convert into Human Human Readable Text and show to application End User


    Another Example for EDI 270 and 271

    1. Provider Smith uses ABC Billing Software.
    2. Provider Smith already signed up with XYZ Clearing House and an ID has been assigned to Provider Smith by the clearing house.
    3. ABC Billing software has the option of generating EDI 270 message and through web service call, it will send the message to the clearing house.
    4. XYZ receives message within few seconds and then identify the message for Payer GOLD. Since XYZ already enrolled with the Payer Gold, so it just forward the message to Payer Gold via web service.
    5. Payer Gold receives the message and prepare the response 271 and send back to the clearing house. Immediately clearing house forward the response to the Provider Smith’s ABC billing software.


    270, 271 healthcare transactions background information

    The eligibility 270 Request and 271 Response is the third most utilized transactions in the healthcare industry, after claims submission and remittance advice transactions. Mandates from the Department of Health and Human Services requiring claim and remittance adoption were contributing factors to claim and remit transaction levels less the 270/271 could be the predominate healthcare EDI transaction. Before the 270/271 transactions were adopted, most eligibility verification was handled over the phone. Since the Healthcare 270/271 has been made a standard industry wide, Providers of Service can send the 270 Request to all Insurance Companies and expect to receive the same uniformed 271 Response format across the board.


    For Source code or Medical Billing Software Consultation, please contact me at vbsenthilinnet@gmail.com

    ZK MVVM Form Binding CRUD with Spring and Hibernate - Part 7

    Some more features.

    ZK + Spring Security Custom Login form

    In this example, we will see step by step how to integrate ZK and Spring security

    ZK + Spring Security Login form–Part 5

    Connect with database and check user exists or not.

    ZK MVC CRUD With Spring 3 + JPA + Hibernate 4 Entity Manager

    A simple CRUD Application based on JPA.