Practice Management

[drbowen]

I suspected that changing the line item billing would fall into the "hard" category based on how you had previously responded to Shameem's request. I also believed that increased flexibility was not going to be easy. Personally, I like the idea of building a new, more flexible table as it seems that this would help accomplish both of these important objectives.

Sam Bowen, MD

[Kevin Yeh]

Sam,
Flexibility/Modularity is also not just limited to the database/schema design. Another piece is in how we implement functionality and re-use code.
Here's an example issue from the current code.

Encounters can be created either through the the Patient/Create Visit menu item or automatically when the calendar entry is updated. While those two methods are doing the same thing (creating an encounter) they each do so with separate code that generates the appropriate sets of queries.

There "should" have been a common function that those two different pages could have used instead of it effectively having been implemented twice. It might have been just copied and pasted from the "forms" code into the calendar code, but it was still done in a less than ideal way in the long term, since now if someone wanted to create an encounter somewhere else in the workflow. Plus, because they are separate pieces of code, they each create the encounter in slightly different ways. The calendar method sets the onset date, while the standard mechanism leaves it blank, and the auto-populated onset date is the same as the date of service which is incorrect for 5010.

So, moving forward, we should strive to do better.

[drbowen]

The OpenEMR code base has been growing organically over the years. While I haven't checked the dates, the feature to create an encounter from the calender may possibly pre-date the other method. In later months (or years) the project decided to move away from adding new features to the Calender with the intent of re-writing the Calender from scratch but the resources and the "rainy day" never came.

There are many examples of overlapping code. Part of the suggestions / plans presented by Tony McCormick, Art Eaton, Jeremy Wallace, Aaron Racho and others is to re-write the functionality of each module as a separate new module that does not depend on the earlier code. As each feature gets replaced we would be able to make the entire code base more modular, and start separately out the GUI interface from the business logic. This is not to say that existing code could not be recycled if dong so helps accomplish the separation of the GUI, business logic and database layers into separate layers.

I have been pushing to make the Practice Management module one such module. Having a new table to base this on, would further several long term goals.

Sam Bowen, MD

[Kevin Yeh]

Sam,
The ar_activity table may be sufficient for the task. However, I must point out that there was a desire to try to switch to InnoDB so we could use transactions and maintain foreign keys/referential integrity between tables, and the current ar_activity table is incompatible with InnoDB

Code: Select all

ERROR 1075: Incorrect table definition; there can be only one auto column and it must be defined as a key

SQL Statement:

ALTER TABLE `openemr`.`ar_activity` ENGINE = InnoDB

[Kevin Yeh]

From today's phone conversation, it is clear that at least one piece of functionality that is missing/needs significant improvement is tracking of co-pays.
Sam explained it, but I am going to try to describe it to make sure we are all on a similar page.

Typical office work flow.
Patient arrives presents their insurance information to the front desk.
At that time, the front desk staff reviews insurance card and notes a co-pay amount that would apply to an Eval/Management CPT code and collects cash, check or charge at that time.
Patient then sees provider, then goes back to the front desk to check out. If there are no other charges besides the E/M for that visit, no additional monies need to be collected. However, if there were additional procedures the patient may be responsible for additional co-pays which correspond to those "line items". Depending on procedure and insurance company, the amount collected might be a flat amount or a percentage of the fee.

A couple of high level questions. Sam, presumably in your current workflow your patient returns to the front desk with a completed superbill which denotes ICD-9 codes an E/M code, and potentially additional CPT/HCPCS codes. When your front office person sees those additional codes, how do they figure out if there needs to be an additional co-pay involved and for how much? Also, if you are using OpenEMR for this, are you still going to have a superbill, or is the provider going to be responsible for entering the charges after he's done with the patient?


The current implementation is that copays are tracked as entries with negative fee amounts in the billing table, which is bad on multiple levels (no need to go in to all the details, we all agree that it's bad). However the primary deficiency is that there is no way to map that co-pay in the billing table to a specific procedure (also in the billing table).

A proposed implementation is to use a seperate table (either the hypothetical table I mentioned earlier or the existing ar_activity table (with possible modifications for InnoDB support)). Then at each step when co-pays are collected during the visit, an entry in this table would be created with reference to the procedure line item in the billing table, amount, type of payment and possibly other stuff. The entry could also indicated the patient owes a co-pay but wasn't collected at that time. "I forgot my checkbook. I'll gladly pay you Tuesday for a hamburger today... etc... "

Am I missing anything?

[drbowen]

It was great to talk to you, Art, Tony and get a better handle on how billing is handled currently.

The modern trend is to collect co-pays at check-in simply too many people forget there check books and want to pay us in hamburgers on Tuesday. The increasing business difficulty from the “health care reform” is causing practices to fail financially. The new law is predicted to cause 144,000 primary care physicians to leave practice. To survive the the practices have to increase their efficiency by probably 30 percent.

Co-pays come in different varieties.

1) Classic co-pay – the co-pay is a fixed amount and applied to against the E&M code.

2) Variable co-pay – usually a fixed percentage multiplied by all charges. Frequently 20%. Usually we collect an estimated co-pay at check-in of say 20% times a 99213 charge. The balance is due at check out. The co-pays are posted against each line item CPT code, charge and diagnosis.

3) Uninsured co-pay – the estimated fee for a 99213 plus a few labs. In our practice this is $125 due before being seen.

4) Malintent co-pay – The client is clearly trying to be dishonest and commit fraud. We ask for the entire estimated balance up front.

Our current system has the co-pays stored based on the insurance type and auto populates the co-pay field for most visits. We only “look at the card to determine the co-pay” on the first visit. After this the field is auto-populated based on the insurance type and previous visits. The front desk clerk reviews this for correctness and has the option to change the co-pay if it is incorrect or needs to adjusted. Commonly this is due because the insurance type changes for the visit (auto accident, worker's comp).

My staff clear up my confusion of the the different primary insurance question. They definitely start two different encounters if different insurance types are involved on the same day. As an example treatment of a cold while doing a worker's comp laceration requires two different encounters that are file and treated separately.

The way to survive in the future is increasing efficiency and increased patient responsibility for their health care costs. The line item CPT, charge, Diagnosis code, debits, credits, co-pay is important in this new era of increased efficiency. The diagnosis code in particular has to be matched on a single line basis. The co-pay that is a percentage of charge is like this also.

Sam Bowen, MD

[Aethelwulffe]

This is what I hear:
Co-pay settings in patient demographics need to be configured in the following manner with each being an optional additive field:

This patient always has the same co-pay for visits, it is $X
This patient must pay a percentage of the following expected codes: (lists that expand for multiple entries)
This patient must also provide co-pays of x% for the following Labs:

If you set the percentages (0-100%) and the price level for the patient, the co-pay output field will reflect the appropriate amount.

If you do other procedures and labs during the visit that affect the co-pay or require any other additional payment, they get an in-exam room estimate for which you may take their additional payment.

Company policy must dictate the where-when of this, and must be followed to achieve the desired results. You COULD stop taking checks, or simply do the checks as an EFT with vericheck before they go anywhere, assuring that their payment will be processed after they have signed the estimate (from printing statements in OpenEMR). That way, check or credit, you know that they can pay, and you can process the payment immediately. If they are doing the cash thing, they simply must hand over the green stuff at the appropriate times, or hand over the compensatory domestic fowl, hamburger, moonshine, or whatever you use in N.C.

[drbowen]

Triple distilled rye whiskey. Very smooth. No kerosine effect. I prefer Wilkes County of course.

Sam Bowen, MD

[drbowen]

The problem with the check book issue is not that we can't figure out how to validate checks, it is a form of intentional fraud where a large number of people simply prefer not to pay their co-pays at the time of service. Its usually because of economic stress and they feel they doctor can float the co-pay for them and play banker. They intend to pay it later but later never comes. Validating checks is a good practice but doesn't solve the problem of the patient never intended to pay the co-pay. The forgotten check book is just an excuse.

The amount of co-pay is not actually a patient characteristic. It is a characteristic of the group number to which the patient belongs. A company (or individual) purchases a specific policy from an insurance carrier and the co-pay is a characteristic of this specific insurance plan purchase, which is identified by the insurance plan ID. Many insurance companies have a characteristic co-pay. In our Blue Cross / Blue Shield of North Carolina most have a flat co-pay. But not all of the plans sold by BCBS of NC are like this. So for a BCBS plan in North Carolina we could set a default co-pay for any BCBS policy and it would usually be correct. I think the co-pays should be listed with each insurance plan not in the patient demographics.

The percentage co-pays are not for "some of the charges" but all of the charges, E&M codes, labs, x-rays, medications, injection fees, everything.

Sam Bowen, MD

[Kevin Yeh]

Is the co-pay percentage something listed on the patient's insurance card? I know some insurance cards list a specific dollar amount as the co-pay for "office visit." It sounds like you are saying that's not the case for your typical patient population.

Or maybe that's the difference between and "urgent care" visit versus one for "primary care".

I agree with you that it makes more sense to track at the insurance plan level than at the patient level if it's truly going to be the same for all patient on a particular plan. Looks like another factor to keep in mind for database schema changes.