Understanding Insurance Benefits: Cracking the X12 Eligibility Request And Response Code

By Samir Bakhshi,

With healthcare records going digital, common healthcare transactions — be it claims, authorization for a service, referrals to a specialist, eligibility verification, status of a claim, or new plan enrollment — can be performed electronically. This means your healthcare providers can spend less time and resources filing paperwork and making calls, and spend more time on what is most important — YOU, the patient!

We are going to explore an in-depth healthcare transaction that provides you or your provider with your coverage information — this transaction is also known as the eligibility request and response (270/271). These transactions can now be done in real-time — meaning that once a request for eligibility information is sent, the response from the payer is returned immediately (within a few seconds).


Let’s first look at the request for eligibility information — the 270 — with a use case.

Mr. Lifts-A-Lot wants to go see a chiropractor because his back has been giving him trouble. Lifts-A-Lot knows that his insurance plan from Premium Gold Insurance Co. lets him see his PCP (Primary Care Physician) for a co-pay, but wants to find out whether chiropractic services are covered.

Lying in bed to rest his back, Mr. Lifts-A-Lot rings his PCP, Dr. Has-Your-Back, to ask her if she could assist him in figuring whether chiropractic visits were covered; and also confirm his co-pay amount for an office visit. After exchanging pleasantries, Dr. Has-Your-Back takes her patient’s Name, Date of Birth and Member ID, telling him that he could stay on the line while she checks his eligibility… in real-time!

Using her practice management software, Dr. Has-Your-Back enters her patient’s demographic information to generate a 270 request, which will look something like this (though the provider will never see the file formatted like this):

The transaction consists of three sections — the information source, information receiver and subscriber level:

NM1*PR*2*Premium Gold Insurance Co.*****PI*0123456~


Let’s now understand each file line:

Information Source

The Information Source section on the file describes the payer, in this case the insurance company — Premium Gold Insurance Co, with a payer ID of 0123456.

Information Receiver

The Information Receiver section relates to the provider, the requester of the eligibility check. It tells us that the doctor is a person (as opposed to a facility/hospital) named Has-Your-Back with an NPI of 9876543210.

Subscriber Level

The Subscriber Level section is all about YOU, the patient! TRN holds the traceback number for the transaction. NM1 supplies the subscriber’s name — Lifts-A-Lot — and also holds the patient’s member IDMEM0001. Patient’s demographic information, sent in the DMG line, holds the date of birth03/15/1982, and also states that the patient is male.

The EQ line tells us that the provider has asked for eligibility information about 2 services — Physician Office Visit (98) and Chiropractic Services (33).

One could also request a "general" eligibility request to receive coverage information for all services on the plan, and not just a few specific ones.

The above 270 Eligibility Request generated by Dr. Has-Your-Back, is then sent electronically to the insurance company, Premium Gold Insurance Co., to supply benefit/coverage eligibility information for her patient/the payer’s insured, Mr. Lifts-A-Lot, for a regular office visit and chiropractic services.

(Note: there are other lines in the file that wrap around the above, known as the X12 envelope, which determine where/how the message will be routed to, but we shall not examine those in this blog.)

Within a few seconds, the provider’s practice management software receives a response which would look like this (it is then translated so she would never see it formatted like this):


The eligibility response has the same general structure as the eligibility request. The response — comprised of the same sections we saw in the request — also includes a section on subscriber eligibility/benefit information:

NM1*PR*2*Premium Gold Insurance Co.*****PI*0123456~


N3*2150 Pleasant Drive~


The information source — the payer/insurer Premium Gold Insurance Co. — and the information receiver — the provider Dr. Has-Your-Back — file lines remain the same. Let’s jump straight to the subscriber section.

Subscriber Level

The HL, NM1 and DMG lines are identical to the lines in the 270 request. The TRN line is used to reference the original request (the traceback number on the 270).

N3 and N4 supply the patient’s (Mr. Lifts-A-Lot) address, as it appears on the insurance company’s files. DTP supplies dates related to the patient’s coverage, telling us that Mr. Lifts-A-Lot’s plan coverage started on 10/01/2014.

Subscriber Eligibility/Benefit Information

And now what was wanted all along — the patient’s eligibility information! The EB*B line tells us that the patient in question, Mr. Lifts-A-Lot, has a co-payment of $10 for a physician’s office visit. The EB*A line describes that for a chiropractic visit, the patient will incur a 20% co-insurance.

And there you have it! The doctor, using practice management software, was easily able to verify Lifts-A-Lot’s coverage information in just a few clicks, and now Lifts-A-Lot can go ahead and find the best chiropractor, well informed about his coverage costs!

Where PokitDok Comes In

Ain't it hard to read the X12? Does it bother you too that in order to receive two lines of relevant information, one needs to craft a 9 line transaction with a bunch of codes? Well, that is where PokitDok makes it easier for organizations to transmit X12 info using our API — and the fields/arguments use plain and simple English!

Simply put, PokitDok takes the X12 response returned, and translates it into simple-to-read JSON. Not only does the API provide the copay and coinsurance amounts as seen in the above example, but also aggregates the deductible and out of pocket amounts on your plan, if any. Being an open platform, PokitDok gives digital healthcare companies the ability to directly communicate with insurers electronically, helping eliminate the traditional manual and labor-intensive processes!

PokitDok’s JSON 270:

PokitDok’s JSON 271:

How beautiful compared to the X12, right?


The opinions expressed in this blog are of the authors and not of PokitDok's. The posts on this blog are for information only, and are not intended to substitute for a doctor-patient or other healthcare professional-patient relationship nor do they constitute medical or healthcare advice.

  Tags: API, Dev


  Comments: 4

  1. Congrats & thank you for launching this great service! Will there be an open API available that would allow for users to check and see if their physician accepts certain policies? (solving for the narrow network) Use Case: User wants to search for health plans that are accepted by a particular primary care physician. e.g. "Show me all the plans that are accepted by Dr. Harris."

    • Nicole Fletcher

      Hey Rick, Thanks so much for your comment. That's something we're thinking a lot about and, while that information is not currently accessible to us, we hope to be able to solve that issue in the future.

  2. Hi. This is great. Thank you. One question I have is that for service type 98, there are usually multiple different copays, depending upon if the doctor is a specialist or a generalist. How do call the two different types, since they are both service type 98. Thanks.

Your feedback