I need Information about insurance payments

michael_barnett wrote on Tuesday, July 18, 2006:

ok I am still working on the internal billing and accounting aspect of openEMR.

The program has a frontpayment received page that i am revamping to recieve and record payments from insurance companies.

This section is broken out by encounter and further by each code used durring the encounter.

Now i know that insurance companies are loophole wizards and have reason codes for not paying or paying less than they were expected to.

If any of you have information that i could look over or know of important things you would like to be tracked. I’d like to put them into the database so i can run statistical reports on insurance behaviour depending on what code was submitted.

I’d also like this information so i can then invoice the customer with an explanation of why the insurance companies paid what they did and justify what they owe now.

michael_barnett wrote on Tuesday, July 18, 2006:

follow this link to see an example of the patient ledger i am working on

http://www.michaelbarnett.us/pics.html

markleeds wrote on Tuesday, July 18, 2006:

I think you blocked out the bottom of the encounter screen where we record codes and payments.  Here is a link to a screenshot of me seeing myself as a patient.  You can see in the bottom middle frame where I can record whatever payment the patient makes on the day of the visit.  If he decides to pay half with cash and half with a credit card, that’s ok.  If we charge $100 and he only has to pay a $20 copayment, we record the $20 and print him a reciept.  If, months later, his insurance company sends a check for another $30, we go back into the same encounter and record the payment by his insurance company in the same box.  If we know that we will never get the other $50, we can record that as a ‘write off’ in the same place again.  These payments are recorded in the billing table and can be queried by encounter, by entry date, by payment form (including the specific insurance company if it’s an insurance payment) and they can be compared to charges which are also recorded in the billing table.  Recording fees and payments this way should give the data you would need to track insurance reimbursement for particular services based on coding.

http://www.drleeds.com/screenshots

drbowen wrote on Tuesday, July 18, 2006:

This is what would be referred to as a “managed care module.”  For this to work correctly,  the practice needs to enter several different “allowables” for each CPT code where each “allowable” represents the pre-negotiated fee for a particular CPT code.  The system compares what is being entered against what was actually charged and what is the allowable fee.

As an example, a very common CPT in primary care 99213 (established patient, expanded visit).

Cash fee: $75
Medicare:  $50.18
Citna:  $63.04
BlueIns:  $62.32
UltimateHC:  $54.17
etc.

We have at this time 13 different fee schedules x approximately 8,000 CPT codes each. 

The common insurance ploys that need to be monitored are underpayment, undercoding and bundling. 

In an underpayment Citna would “innocently” pay $58.25. 

An undercoding means that BlueIns changes the code from a 99213 to a 99212 and pays us the correct amount for a 99212.   A typical example is that the primary ICD-9 code used does not “justify” the higher charge.  A common example, charging a 99215 with a diagnosis of “influenza” is likely going to be downcoded to 99213.

It is illegal to “unbundle” laboratory charges.  If I have a big chemistry analyzer that runs 150 different automated chemistries and I run a “SMAC 24”.  I am supposed to bill for 24 automated tests using the appropriate code for this.

If my laboratory has three separate smaller machines that run a SMAC 12, a liver panel, a lipid panel as three separate tests.  (24 tests total)  I can charge a SMAC 12, a Liver panel and a lipid panel as separate tests.  This is legitimate because I actually own three separate machines that do the work.  This involves more reagents and more maintenance than the SMAC 150 machine described above.

In bundling, UltimateHC bundles my three tests together and pays me for the SMAC 24 because the reimbursement is lower.  This is also illegal but harder to fight since they have a lot of good lawyers and the difference in fees is relatively small ($3-4).  This doesn’t break the piggy bank of the physician but to UltimateHC $3 x 1 million claims a years ends up being a nice bonus on the bottom line.

Of course Acme US Healthcare pays $4 (yes, 4.00 dollars) for a CBC, CMP (14 tests), lipid panel, TSH and urinalysis.  This battery of tests is bundled together as a “general health panel”.  Well, let me come clean.  They do pay $6 for the phlebotomy charge.

The names of the these insurance companies have been changed to protect the innocent.  Any resemblance to actual insurance companies is completely accidental.

Remember,  The insurance company computers only read the first line of diagnosis codes for any CPT code.  It is important to code each CPT code with the best matching ICD-9 code, line by line to try to get what is owed to you.

For this type of module to work correctly it will be necessary to enter all the separate charge schedules.  Your software will have to check that the actually CPT code being reimbursed is the one you actually charged (checks for bundling and downcoding) and that the fee received is the one expected (checks for underpayment).  It will need to flag the operator.

One of the ways to prevent downcoding is to check the “justification” of CPT codes to ICD codes on the front end before billing.  Picking up that no reasonable insurance company is going to pay a 99215 for the flu. 

Maybe the doctor should have coded hypoxemia or shock instead.  After all, the patient with the flu had an oxygen concentration of 85% and a blood pressure of 75/30. The doctor performed a CMP, ECG, CXR, and CBC.  Medical decision making was complex.  Risk of morbidity and mortality is high.  In this case the 99215 is actually the appropriate code.

Sam Bowen

michael_barnett wrote on Tuesday, July 18, 2006:

Good god Sam i had no idea trying to get paid for a doctor was such a pain.

Man i will never complain about a late check again  from the boss. lol

ok every code has an icd-9 thanks for explaining the justification feature I’ll make sure to put that back lol

you said "
For this type of module to work correctly it will be necessary to enter all the separate charge schedules. "

where can i get charge schedules?

what does the payment from the insurance company look like ?

i mean you mention they downgrade codes. so do they send you back a list of codes and what they paid?
do they group the codes that they paid with icd-9?

do you think a report of underpayments by insurance companies that refrenced encounters would help a doctor get his due if say at the end of the year you could prove underpayments.i say at the end of the year becasue the dings will look more like a dent and would be worth sending a legal letter to help them correct their underpayments.

Thanks also Mark I did not play with that feature or did not see it the way you have it I’ll look closer. But i do want the codes and descriptions in the ledger.

michael_barnett wrote on Wednesday, July 19, 2006:

hehe the copay.php that comes with the zip file only has the input box and a save button.

I went to the CSV and downloaded the latest one that looks like yours.

were there database changes as well???

markleeds wrote on Wednesday, July 19, 2006:

There’s a zip file? :slight_smile:

No, there are no database changes at all.  This payment entry method leverages existing code and database structure.

Look at the description for the table ‘billing’.  When you enter an ICD9 or CPT4 code into an encounter, this is where that information is stored.  Copays are also recorded in this table, which seems strange, but this has been around for a long time.  At least as long as OpenEMR has been on Sourceforge.  The amount paid is saved in the ‘code’ field.  The trick is that when you save an ICD9 or CPT4, the field ‘code_text’ stores the text description of the code.  When a COPAY is saved, the ‘code_text’ field previously was filled with the text ‘COPAY’.  This was completely redundant and unecessary.  I just added the widgets you see in the copay screen and arranged to have the payment form stored in ‘code_text’.  It stores strings such as ‘credit’, ‘cash’, ‘check’, ‘insurance: insurance_company_name’…  It’s just a way of using what was already in the main program from way back with minimal modification.  The term COPAY could be changed to PAYMENT or something else in the future possibly so future developers will not be confused by the term.

This is not meant to replace the use of SQL-Ledger and fee_sheet for the majority of users who are probably using these tools.  It is just an alternative that I have been using, developing and studying in the office since January.