How to process Co pay, Co Insurance and Deductible Amount in Insurance Payment Posting

Let us first see what is Co-pay, Co insurance and Deductible

Co-payment

A co-payment, or co-pay, is the flat amount you pay at the time of a medical service or to receive a medication. All insurance companies provide these costs to you up front. Insurance companies use these co-pays in part to share expenses with you.

Co-pay example: A doctor’s office visit might have a co-pay of $30. The co-pay for an emergency room visit will usually cost more, such as $150. However, there is a maximum amount you will pay for coinsurance and co-pays. This is called the coinsurance and co-pay maximum.

Coinsurance

Coinsurance and co-payments are not the same thing. A co-payment is a specific amount that you pay to the provider before you meet your deductible. Coinsurance is a percentage of a provider’s charge that you may be required to pay after you’ve met the deductible.

Example of coinsurance: Say you’ve already paid out (or met) your $147 Medicare deductible and your coinsurance is 20 percent. For a $100 health care bill, you would pay $20 and your insurance company would pay $80.

When you’ve met your deductible, you’ll have to pay coinsurance (Medicare is set to 20 % of the provider’s charge) until you reach your out-of-pocket maximum. After that, the insurance company will pay for all covered services to the policy maximum for the remainder of the year

Deductible

A deductible is the amount you pay for health care services before your health insurance begins to pay. For Medicare, this resets every year on January 1st.
Part B Deductible for 2014: $147 per year (for most people).

Difference Between Co-pay and Coinsurance

Coinsurance: Coinsurance is a term used for a percentage amount you are responsible for. For example if your insurance policy is 80/20, then the insurance is 80%. You are responsible for paying 20% of your bill. The 20% that you owe is called "coinsurance." This amount can vary as the cost of the services performed varies.

Co-pay: A co-pay is usually a flat fee. For example, every time you go to the doctor you pay a 25.00 co-pay for the office visit, regardless of the level of service you receive.

While doing insurance Posting in PMS Software, line item may contain Co pay, Co Insurance and Deductible. The following are guidelines to handle the same.

PR - 1 Deductible Amount

Description:

In insurance policy terms, a deductible is the amount of money which the insured party must pay before the insurance company's own coverage plan begins. In practical terms, insurance companies include a deductible in their policies to avoid paying out benefits on relatively small claims.

Action:

1. We need to bill the patient.

2. If the patient has another insurance coverage which covers deductible we can file to that insurance, if the policy not cover primary deductibles we have no other way rather than billing the patient.

Claim processed as PR - 2 Coinsurance Amount

PR - 2 Coinsurance Amount

Coinsurance amounts are generally 20% of the Medicare fee schedule. Physicians must collect the unmet coinsurance from the beneficiary. Consistently waiving the coinsurance may be interpreted as program abuse. If a beneficiary is unable to pay the coinsurance, the physician should ask him or to sign a waiver that explains the financial hardship. If no waiver is signed, the beneficiary’s medical record should reflect normal and reasonable attempts to collect, before the charge is written off.

Action :

1. We need to file the claim to secondary insurance

2. If there is no secondary insurance we can bill the patient

EOB - PR - 3 Co-payment Amount

PR - 3 Co-payment Amounts

Description:

Co-payment A specified dollar amount or percentage of the charge identified that is paid by a beneficiary at the time of service to a health care plan, physician, hospital, or other provider of care for covered service provided to the beneficiary.

Cost sharing the general set of financial arrangements whereby the consumer must pay out-of-pocket to receive care, either at the time of initiating care, or during the provision of health care services, or both. Cost sharing can also occur when an insured pays a portion of the monthly premium for heath care insurance.

Action:

1. We need to bill the patient.

2. If there is any other insurance coverage if the patient has, we can bill to that insurance also.

  Co-pay Work Flow

1. Patient walks into doctor office .

2. People at the Reception desk ask the patient insurance card (it  is like credit card) and see any amount mention in the card as co-pay.   If not, they will do the eligibility check and see whether any co-pay is required. Insurance eligibility check will give the complete details     where insurance is active , any co-pay amount to be paid, etc..

3. Once they determined, if co-pay amount need to be paid, then reception desk will do either of the following
      Option 1:    Will collect the amount and give the Patient receipt.  
      Option 2:    Will Inform the patient that he/she need to pay copy after the Insurance payment is over. After insurance payment is over, we will  send the  patient statement to you and then you can pay your co-                      pay amount.
       Option 3:    Will inform the patient after the Insurance payment is over, we will send the claim to your secondary insurance and try to get  the co-pay amount.
   
   In most cases, doctor office will not collect the co-pay amount at the time of visit because either they may not known the exact amount or it   may be cover by the secondary insurance. Please remember, the exact co-pay amount is calculated after insurance processing the claim and will  be informed in the EOB.

4. Billing company send the claim to Insurance company.

5. Insurance company process the claim and if any co-pay has to paid by patient, then they will mention that amount in the EOB.

6. Now the billing company transfer that amount from insurance side to patient side if patient does not have secondary insurance.   (Move to Patient responsibility)   if patient has secondary insurance, then they will send to secondary insurance and try to collect it from secondary insurance.   Please remember, while sending the claim to secondary insurance, we must send the patient primary insurance information and    what amount has been paid and what amount has been left over.

7. If secondary insurance does not cover that amount, then it will be transferred to patient responsibility.

  Deductible Workflow

Simple example, once you taken the policy , insurance company says, first patient has to Pay $ 500 and then insurance will start paying for the medical services

1. Patient walks into doctor office A.
2. Doctor done some medical services to Patient.
3. Billing Department send the claim to Insurance. Let the bill amount is $ 200.
4. Insurance find that the patient has to pay $ 500 first and then they can start paying.
5. Now the insurance company send the EOB saying $200 is Deductible. Please note, here insurance company does not pay any amount. And also the insurance company system reduces this $ 200 from $ 500 and update the record balance as $300 deductible balance
6. Billing Department transfer this $ 200 to patient responsibility if the patient does not have secondary insurance. If the  patient has secondary insurance, then claim send to secondary insurance for this amount.

**********************************
1. Same Patient walks into same doctor office A or doctor office B or lab.
2. Some medical Services done to Patient.
3. Billing Department send the claim to Insurance. Let the bill amount is $ 100
4. Insurance find that the patient has to pay $ 500 first and then they can start paying. And also records says $200 already met in the previous  visit.
5. Now the insurance company send the EOB saying $100 is Deductible. Please note, here insurance company does not pay any amount.
    And also the insurance company system reduces this $ 100 from $ 300 and update the record balance as $200 deductible balance.
6. Billing Department transfer this $ 100 to patient responsibility if the patient does not have secondary insurance. If the patient has secondary insurance, then claim send to secondary insurance for this amount.

**********************************

1. Same Patient walks into same doctor office A or doctor office B or lab.
2. Some medical Services done to Patient.
3. Billing Department send the claim to Insurance. Let the bill amount is $ 600
4. Insurance find that the patient has to pay $ 500 first and then they can start paying. And also records says $300 already met in the previous visit.
5. Now the insurance company send the EOB saying $200 is Deductible and Payment is $400
6. Billing Department transfer this $ 200 to patient responsibility if the patient does not have secondary insurance. If the  patient has secondary insurance, then claim send to secondary insurance for this amount.

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

EMR SOAP Notes

HL7 OBX - observation/result segment

How to create ZK Maven Project in Eclipse kepler

Understanding EOB - Explanation of Benefits

---

HL7 Data types

ZK MVVM Combo Box value Converter

ZK MVVM List box with check box – Simple Example

ZK MVVM Simple List Box Example

MSH - Message Header Segment

EOB - An explanation of benefits

Here is the workflow on How does the EOB Statement comes to the Provider Office.

1. The patient visits the Clinic or Provider office.
2. The doctor sees the patient and render the Medical Service.
3. The Bill(Claim) is prepared to the Insurance Company via Clearing House.
4. Insurance Company Process the Claim and Send the Check Payment to the Provider.
5. Along with the Check, a statement (EOB) will also send to the Provider office. The Statement tells the details of the Payment.

An explanation of benefits (commonly referred to as an EOB form) is a statement sent by a health insurance company to covered individuals explaining what medical treatments and/or services were paid for on their behalf.

EOBs, or explanation of benefits, are the forms that are sent out by the insurance carriers in response to the claims that were filed. If the payment is being made, the EOB is either attached to or included in the check. If no payment is made the EOB should contain information explaining why no payment was made.

Electronic Remittance Advice – ERAs
Sometimes EOBs are received as an electronic file called an ERA or electronic remittance advice. The ERA would replace the paper EOB. Usually, a provider has to sign up to receive ERAs. In order to receive ERAs, the provider must be set up to receive their payments through EFT or electronic funds transfer. This is when the insurance carrier transfers any payments due to a provider directly into a specified bank account through electronic funds transfer.

The insurance companies like ERAs because it saves them in printing, paper, and postage. They no longer have to print out the checks and eobs and have them stuffed into envelopes and mailed to the provider. With ERAs, they just create the eob as an electronic file usually in a format called an 835. The provider downloads the ERA 835 file from h the clearinghouse.

The advantage of receiving ERAs for the provider is that it eliminates the mail time and can cut down on paper. If the provider stores the file on their computer they don’t have to file the paper copy of the eob. The other advantage is that most practice management systems will use the ERA to automatically post the payments. This saves a lot of time manually entering the payments.

What action needed at the Provider Office when they receive EOB?
Once the provider downloads the ERA the payments must be applied to the appropriate patients and any secondary claims should be submitted or patient balances should be billed. Sometimes ERAs contain rejections and those should be handled as well. This Process called Insurance Payment Posting

EOB includes following details which is necessary during payment posting process in order to post the payments to the respective patient account:

• Payer Name: Name of the Insurance company
• Payer Address: Address of the Insurance company
• Patient Name: Name of the patient
• Provider Name and address
• Member ID#: It is also known as policy identification number
• Claim received Date: It is the date the claim received by payer from provider (Billing office).
• Payment or denial date: It is the date the claim processed or denied by payer.
• DOS – Date of Service: It is the date service provided from healthcare provider to patient.
• CPT Code – Procedure code
• Billed Amount – It is also called as charge amount for each service performed by healthcare providers.
• Claim Number – It is also called as Document control number or Transaction control Number, which will be assigned by the payer for each claim as soon as they receive in their system.

If claim paid then following details:

• Allowed Amount: It is an amount, payer deems fair for a specific service or procedure. AA = PA+ PR.
• Paid amount: Paid Amount = Allowed Amount – Patient responsibility.
• Patient Responsibility: This is the balance percentage of reimbursement that the patient has to pay according to his policy with the insurance company. This is paid either by the patient or his secondary insurance if they have one.
• Write off Amount: It is an amount that is waived off by the provider. Write off Amount = Billed Amount – Allowed Amount.
• Check#
• Check date
• Electronic Fund Transfer# (EFT#)
• EFT date

If claim denied, then it will have the following details.

• Denial Code
• Denial Reason

You can also download some Sample EOBs

1. Simple EOB 1
2. Simple EOB 2
3. Co-pay Example
4. EOB With Multiple Claims
5. EOB With Multiple Check (More than one Posting or Batch)
6. EOB With Multiple Check (More than one Posting or Batch) 

How to Read and Understand an EDI File ?

EDI Instructions

Understanding EDI Structure

What is an EDI ?

Medical Billing Workflow

Note: In medical billing, people often use different terms to refer to the same thing. Here are some of the most commonly used variations:

• A Doctor is also referred to as a Physician or Provider.
• A Doctor’s Clinic is also called a Doctor’s Office, Physician’s Office, Provider’s Practice, or Provider’s Facility. The terms facility, practice, clinic, and office all refer to the place where a patient meets with a doctor.
• Insurance is also referred to as a Payer or Carrier.

Use Case 1: In-House Billing

A patient calls or walks into the Physician’s (Doctor’s or Provider’s) office to schedule an appointment.

On the appointment day, the patient checks in, provides demographic details (name, DOB, address, etc.), and gives insurance information.

The doctor reviews previous medical records and prescribes treatment.

ICD Codes (Diagnosis Codes)

• Each disease is represented by an ICD Code (also called Dx Codes, Problems, or Diagnosis Codes).
• ICD codes help classify diseases, symptoms, and causes of death.

CPT Codes (Procedure Codes)

• Each treatment is represented by a CPT Code (also called Procedure Codes).
• CPT codes describe the procedures performed on the patient.

After the consultation, the patient leaves, and the doctor’s office submits a claim to the insurance company for payment.

Use Case 2: In-House Billing with Two Insurances

Some patients have multiple insurance policies:

• The first insurance billed is the Primary Insurance.
• The second insurance is the Secondary Insurance.
• If applicable, the third is the Tertiary Insurance.

Once the primary insurance pays its portion, the balance is sent to the secondary insurance for further processing.

Use Case 3: Self-Pay

Patients without insurance are considered self-pay and must pay for services out-of-pocket.

The clinic generates a statement and sends it to the patient for payment.

Use Case 4: Patient Responsibility

Some insurance policies only cover a percentage (e.g., 80%). The remaining amount is the patient's responsibility.

The balance is billed to the patient after the insurance company processes the claim.

Use Case 5: Clearinghouse Workflow

After submitting a claim, the billing team sends an EDI 837 file to the clearinghouse.

The clearinghouse validates the claim and forwards it to the appropriate insurance company.

Once processed, the insurance company generates an EDI 835 file (electronic remittance advice) and sends it along with the Explanation of Benefits (EOB).

Use Case 6: Co-Pay Workflow

A co-pay is a fixed amount the patient must pay at the time of service.

Co-pay details are verified through the patient's insurance card or an eligibility check.

Use Case 7: Deductible Workflow

A deductible is the amount a patient must pay before insurance coverage begins.

For example, if a patient has a $500 deductible, they must pay that amount first before the insurance covers any costs.

Use Case 8: Lab Billing

If a doctor requests lab tests, the samples are sent to a laboratory.

Once results are ready, the lab's billing department submits a claim to the insurance company for payment.

Example Patient Conversation

Jake: Calls the MyFirstHealth clinic.

Linda: Hello, this is Linda from MyFirstHealth Clinic. How can I help you?

Jake: Hi, I’d like to book an appointment with Dr. John for today at 5:30 PM.

Linda: Sure! Have you visited our clinic before?

Jake: No, this is my first time.

Linda: Okay. May I have your last name, first name, and date of birth?

Jake: My last name is Jake, my first name is Mike, and my DOB is XX/XX/XXXX.

Linda: Got it! Please arrive 15 minutes early to complete the check-in process.

Jake: Will do. Thanks!

At 5:15 PM, Jake arrives at the clinic and checks in.

Jake: Hi, I have an appointment with Dr. John at 5:30 PM.

Linda: Welcome, Jake! Do you have insurance?

Jake: Yes, my employer provides insurance. Do you need that information?

Linda: Yes, please.

Jake: Apart from my employer’s insurance, I also have a family insurance plan.

Linda: Great! We’ll list your employer’s insurance as primary and your family plan as secondary.

Jake: That makes sense. Thanks!

ZK Dynamic Menu

ZK Dynamic Menu Part 5

ZK Dynamic Menu Part 4

ZK Dynamic Menu Part 3

ZK Dynamic Menu Part 2

ZK Dynamic Menu Part 1

Create a Report with ZK using iReport 5.1.0 and JasperReports

HL7 Parsing–My Own Parser

Preauthorization

ZK Dropupload example

Hibernate Custom validator to validate Multiple email ids

ZK List box inline Editing with Add New and Delete action

ZK Example for inline Editing with Add New and Delete

Patient Demographics and Patient cases

How to get Current Date and Time and store in the bean

Maintaining Patient Insurance

---

Many patients only have one insurance plan but it is possible for a patient to have two or three medical insurance policies. The first insurance billed would be the primary insurance. The next one billed would be the secondary, and the last would be the tertiary.

After payment is received from the primary insurance, the secondary is then billed on a new claim with the information regarding payment from the primary insurance in the form of a photocopy of the explanation of benefits. If there is a tertiary insurance, it would be billed after payment from both the primary and secondary insurances is received. Copies of both
the primary and secondary eobs would be attached to a new claim with the tertiary insurance information on it.

Another example of a person having two insurances is when both the husband and the wife work and both are eligible for health benefits from their employers. Their own policy would be primary and the spouse’s would be secondary. If they have children there are rules that determine which policy is prime for the children.

How patient insurances are maintained  in the EMR/PMS software's ?

Today, software's are maintaining the patient insurance in difference ways. Each method has its own cons and pros. I will list those methods which i found in my past experience.

Before getting into detail, let us see the terms "Primary",  Secondary, Tertiary and 4th Insurance". In some software, instead of calling 4th Insurance, they will call as Quaternary Insurance.

Actually, there is no defined process or method to identify which is patient primary insurance , and which is patient secondary insurance, and so on. For more details, please download this article and you will know how it has been identified. Since there is no defined way, most of the time, reception people will enter the secondary insurance information into primary and vice versa. That's the reason, all the software's providing swapping option for the insurance

And also, we should know how secondary insurance billed and get paid. Please download this document to know more on that.

Now let us see how software's are maintaining the patient insurance.

Method 1 : Maintain 2 or 4 insurance at the Patient Level

Here you can always maintain 2 or 4 insurance at active state. Give important to the word "Active" here. But, HIPAA EDI 837 Transaction allow up to  11 insurance.  So what happens, at one point of time, the existing insurance get expired and patient got new insurance ? Well, you cannot remove  that insurance from the system it because it is tightly linked to Billing (Claims) Module. So only the option is to de activate the existing primary insurance and add new insurance in the active state as primary Insurance.

The advantages in this method is : Insurance are maintained only at one place i.e. at the patient level. So any changes done here, it will impact all the claims linked to that.  This might be useful when there is error in the data entry and after the correction, they want to re submit all the claims linked to that insurance.

And also, at one point of time, there will be huge number in the inactive state, and no idea which claims are linked to that.

But what happen, if the patient is coming for two different visit types : For example, you may have a patient that is being treated for injuries sustained   from an auto accident that is covered under one insurance policy; yet that same patient may receive treatment during the same visit for a condition    unrelated to the auto accident where a different policy may be billed. So in this case, you need to maintain two primary insurance dependent on the visit type.In the above method, it is not possible, so that is one of the disadvantage.

Method : 2

Another way is to clone the patient demographics insurance while claim is created and therein after maintain the copy of all insurance at the claim  level. 
 
In this method, initially, the insurance are maintained at the patient level. But when the claim is created, software will take a copy of all insurance and will maintain along with part of the claim details. So here, after the claim is created, the insurance at the patient level is plugged off and will not have tightly linked with the claim. If any error in the policy details, of course, first we should correct at the claim level and then at the patient level for error free future claims.

if the patient is coming for two different visit types, then we can easily handle here because, we need to change only at the claim level.

Method : 3

And final method is patient case. This method not only to maintain the insurance, but it can also provide a template kind of stuff to create same  kind of claim data for the same patient again  and again to save the time.

In order understand, simply you can think patient case is nothing but to maintain group of insurances.  Let us see detail now.

EDI Transactions

The HIPAA transactions1 and code set standards are rules that standardize the electronic exchange of health-related administrative information, such as claims forms. The rules are based on electronic data interchange (EDI) standards, which allow for the exchange of information from computer-to-computer without human involvement.

A "transaction" is an electronic business document. Under HIPAA, a handful of standardized transactions will replace hundreds of proprietary, non-standard transactions currently in use. For example, the HCFA 1500 claims form/file will be replaced by the X12 837 claim/encounter transaction. Each of the HIPAA standard transactions has a name, a number, and a business or administrative use. Those of importance in a medical practice are listed in the table below.

 




      

Transaction	Number	Business use
Claim/encounter	X12 837	For submitting claim to health plan, insurer, or other payer
Eligibility inquiry and response	X12 270 and 271	For inquiring of a health plan the status of a patient.s eligibility for benefits and details regarding the types of services covered, and for receiving information in response from the health plan or payer.
Claim status inquiry and response	X12 276 and 277	For inquiring about and monitoring outstanding claims (where is the claim? Why haven.t you paid us?) and for receiving information in response from the health plan or payer. Claims status codes are now standardized for all payers.
Referrals and prior authorizations	X12 278	For obtaining referrals and authorizations accurately and quickly, and for receiving prior authorization responses from the payer or utilization management organization (UMO) used by a payer.
Health care payment and remittance advice	X12 835	For replacing paper EOB/EOPs and explaining all adjustment data from payers. Also, permits auto-posting of payments to accounts receivable system.
Health claims attachments (proposed)	X12 275	For sending detailed clinical information in support of claims, in response to payment denials, and other similar uses.

How EDI Works
 

Doctor diagnosis the patient and provide the treatment for the identified disease. Billing Team prepare the bill(claim) and the claim is transmitted into an EDI Document format called as 837 Health care claim. Then the EDI 837 Document securely transmitted to the insurance company via clearing house.

Then the Insurance company processes the claim which comes in the electronic format and provide the necessary reimbursement for the provider for the treatment given to the patient.

Why You Need EDI – the Benefits

• Lower costs
• Higher efficiency
• Improved accuracy
• Enhanced security
• Greater management information

Interest to see some sample EDI Documents. Please check here.

837 Professional

Professional billing is responsible for the billing of claims generated for work performed by physicians, suppliers and other non-institutional providers for both outpatient and inpatient services. Professional charges are billed on a CMS-1500 form. The electronic version of the CMS-1500 is called the 837-P, the P standing for the professional format.

837 Institutional
Institutional billing is responsible for the billing of claims generated for work performed by hospitals and skilled nursing facilities. Institutional charges are billed on a UB-04.

Both sets of 837 specifications are same. The only differences would be claim specific data that pertains to a single transaction. All three transactions contain ISA, GS and ST segments but some data and qualifying codes are specific to the type of 837. Another way to quickly identify which type of 837 is being encountered is by the codes sent in the GS-08 or in the ST-03. Professionals use a 005010X222, Institutional uses a 005010X223 and Dental uses a 005010X224.

EDI Tool

Create EDI 270 from JSON

Parse EDI 835 into PDF

Create CMS 1500 Form using JSON

Parse EDI 837p to CMS 1500 Form

For 837 Institutional sample, please check here

        

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

Health care Coding system

ZK upload PDF to server and show in the screen using MVVM

ZK Quick InputBox

HL7 Parsing

VB.NET Examples

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

More & More Validation using Hibernate Validator

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

Validation using Hibernate Validator

EDI 270–5010 Documentation– 2000C SUBSCRIBER LEVEL

2000C Hierarchical Level

EDI 270–5010 Documentation–2000B Information Receiver Name

EDI 270–5010 Documentation–2000B Information Receiver Level

 

EDI 270–5010 Documentation–2100A Information Source Name

2100A Information Source Name

EDI 270–5010 Documentation–2000A Hierarchical Level

HL –   Hierarchical Level

EDI 270–5010 Documentation–BHT – Beginning of Hierarchical Transaction

BHT – Beginning of Hierarchical Transaction

EDI 270–5010 Documentation - ST – Transaction Set Header

EDI 270–5010 Documentation - GS – Functional Group Header

GS – Functional Group Header

Reverse-engineer POJOs from a database

Masked Input Component

Small Custom ZK Component based on jquery

Types of Reimbursement

Java Examples

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

	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  

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  

---

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

Create an account in our Nagata EDI Tool and check  HIPAA X12 EDI Transactions sets.

Here is the demo link

https://demo.nagatabilling.com/NagataEDITool/login.zhtml 

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

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

Storing Image in the Database

Login form CSS

Login form CSS

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

jQuery Masked Input Plugin

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

Bug Fixing.

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

ZK Theme customization for each user.

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.

Medical Billing Process in detail

Clearing House

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

Spring security 3 integration with hibernate 4

ZK composite component Example

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

Change Look and Feel

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

Presentation Layer using ZK Framework