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

    Create an account in our Nagata EDI Tool and check  HIPAA X12 EDI Transactions sets.
    Here is the demo link

    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