POS workflow tests

fred0 wrote on Wednesday, June 03, 2009:

If anyone here has any experience with POS workflows when you have inhouse_pharmacy set to true, I’d love to hear how you manage accepting payments for products and billing for insurance on the same encounter and for product only sales. I can’t seem to find a way that works properly.

Here’s my series of tests:

Test 1
1. Add encounter
2. Add CPT & ICD9 and justify on fee sheet
3. Appears in billing view as ready to bill

NOTES - none, worked as expected for basic billing with no product

Test 2
1. Add encounter
2. Add CPT & ICD9 and justify on fee sheet
3. Add co-pay on fee sheet
4. Appears in billing view as ready to bill with COPAY as entered value from fee sheet

NOTES - while this mostly worked as expected, the COPAY entry has no associated payment type (ie - cash, credit card, check, other)

Test 3
1. Add encounter
2. Add CPT & ICD9 and justify on fee sheet
3. Go to checkout form and add partial payment
4. Appears in billing view as billed with COPAY as amount from checkout and an error in red saying, "Note: This code was not entered by an authorized user. Only authorized codes may be uploaded to the Open Medical Billing Network for processing. If you wish to upload these codes, please select an authorized user here."

Test 4
1. Add encounter
2. Add CPT & ICD9 and justify on fee sheet
3. Add non-drug product that is taxable
4. Appears in billing view with only CPT & ICD9 codes and amounts
5. Now, go to checkout and pay amount for product & product tax only
6. Back to billing view, encounter shows as billed, the payment for the product amount & tax is shown as COPAY and the TAX for the product appears as its own item (but doesn’t get added to the HCFA total on print). Also get the error “Note: This code was not entered by an authorized user. Only authorized codes may be uploaded to the Open Medical Billing Network for processing. If you wish to upload these codes, please select an authorized user here.”

NOTES - I tried Test 3 & 4 with a user who had the "Authorized" checkbox first disabled and then again enabled with the same error result. Also tried it as the admin user with the same error result. Besides the error, the use of the checkout popup is NOT AT ALL what I would have expected (see summary below).

Test 5
1. Add encounter
2. Add CPT & ICD9 and justify on fee sheet
3. Add non-drug product that is taxable
4. Appears in billing view with only CPT & ICD9 codes and amounts
5. Go to EOB interface, find & open encounter
6. Services show as 1 line item, products as another. TAX fails to appear at all.
7. Make patient payment for product amount only
8. Back to billing view, encounter now shows only services amount, no taxes, no COPAY as expected but has no record of payment type other than a check number (can’t set credit card/cash/other/etc)

NOTES - This is the one workflow that came anywhere to close to working right. The main failure was the lack of TAX in the EOB interface. The other 2 failures were the lack of payment type in the EOB interface and the fact that it is overly complicated for doing POS checkout at the front counter. And EOB should only be handled by accounting, not the front office.

Test 6 (product only sale)
1. Add encounter
2. Add products to fee sheet (no CPT/ICD9 codes)
3. Appears in as unbilled billing view with no codes or charges
4. Appears in current patient encounters list with no detail or indication of type
5. Use Checkout popup to accept payment
6. Appears in billing view as billed with COPAY and TAX as line items

NOTES - failed as expected per Test 4

Test 7 (product only sale)
1. Add encounter
2. Add products to fee sheet (no CPT/ICD9 codes, no Provider)
3. Appears in as unbilled billing view with no codes or charges
4. Appears in current patient encounters list with no detail or indication of type
5. Does not appear in EOB basic search for open invoices with no other search parameters set
6. Search EOB for All with either date or name set finds invoice but shows no amount in Charge column
7. Open invoice in EOB shows charges but TAX is missing

NOTES - failed as expected per Test 5

Test 7 (Prepay)
1. Add and select new patient
2. Choose Prepay popup
3. Add payment amount and save
4. New encounter created on today’s date as DOS with COPAY of entered prepay amount

Another take:
1. Use Prepay popup for patient with balances due
2. Shows due balances with DOS for each and payment fields

NOTES - Not quite what I expected from the name. We require new patients to pre-pay for their first appointment and usually take these pre-payments several days in advance of the appointment and the name suggested that this would be that kind of function. However, prep-pay in this case seems to mean a patient paying a charge before the insurance check arrives. I’m not really sure why one would use this instead of the EOB interface and why it records the payment as a COPAY.
For my purpose as described here, this doesn’t work since the DOS can’t be set. While it would have been a nice to have, it’s easy enough to use the Comments in the appointment add/edit to note the payment received & details to be added once the appointment is billed.

In summary:

I could not find a way to properly deal with in-house product/drug sales and POS checkout and insurance billing.
While the Checkout popup does provide payment type entry, applying the payment as a COPAY was not what I would have thought it would do. I had expected some way to do POS sales. And at the very least, I would have expected it to enter the payment as A/R and not as a COPAY.
Using the EOB interface applied the payment properly, but was overly complicated for front office (and should only be available to accounting users anyway), didn’t record payment types and didn’t calculate and include tax.

What is needed is a Checkout window that:
1. Allows one to select which line items to pay for at checkout (probably checkboxes to the right of each line item) and calculates the total of those selected items in the amount paid box.
2. Has payment type selection
3. Has COPAY as an optional line item.
4. Calculates tax.

That way, one could accept payments for products while leaving the services to be billed to insurance. Or one could select all for a patient with no insurance who is paying the full amount themselves. The COPAY amount would be added to the amount due/paid in checkout, but separately applied to the insurance billing.

In function, that would mean that the amount paid and payment type would be recorded in ar_activity & ar_session and split up for line items (the way an EOB entry would). If there is a copay set, that value is subtracted from the total and recorded in the billing table as is done by both the fee sheet and the current Checkout popup.

Finally, a product only sale transaction with tax is impossible as far as I can tell.
However, even with a proper POS checkout function, should one want to do a product only sale transaction, the only way to accomplish that is to create an encounter for the sale. Kind of a weird way to do product only sales, but not terrible. A quick way to handle this is to add a calendar category like "Product Only Sale" so that when creating the encounter this category can be used to set it apart from regular appointment encounters.

fred0 wrote on Wednesday, June 03, 2009:

Thinking some more about co-pays, does the insurance co-pay setting in patient demographics do anything anymore? If not, it should also be used on the pos checkout.
Ideally, a co-pay field should only appear in checkout if there is a CPT coded charge associated with the encounter. Since there are 3 insurance (and co-pay fields) in demographics, it would be handy to have any of those 3 that have values appear automatically and be selectable by checkbox in the same way as line items as I described in the first post. As it stands, neither the fee sheet nor checkout forms cue the user to the value or exisitance of the co-pay. One would either have to remember them per patient or go look at the demographics before going to the fee sheet or checkout form. Neither method being very efficient.

fred0 wrote on Wednesday, June 03, 2009:

Since it’s late at night, I’m just going to keep talking to myself here…

First, I should have gone and looked at the code to begin with, but I didn’t so I missed this comment from Rod at the top of pos_checkout.php:

// (1) Drug sales may or may not be associated with an encounter;
//     they are if they are paid for concurrently with an encounter, or
//     if they are “product” (non-prescription) sales via the Fee Sheet.
// (2) Drug sales without an encounter will have 20YYMMDD, possibly
//     with a suffix, as the encounter-number portion of their invoice
//     number.
// (3) Payments are saved as AR only, don’t mess with the billing table.
//     See library/classes/WSClaim.class.php for posting code.
// (4) On checkout, the billing and drug_sales table entries are marked
//     as billed and so become unavailable for further billing.

My bad, brain was seizing up from trying to manage too many projects at the same time. And it’s looking more and more like this thread should be under “Help” and not “Developers.” Sorry.

Next, now that believe that I have found that the way to do product sales without an encounter is via the prescription interface (am I right?), a couple of things still seem not quite right:

Is the sequence fill out prescription>save>go to list prescriptions>open prescription>save & dispense? Because that seems like a waste of time.

Choosing an item from the in-house list doesn’t auto-fill the price field.

Clicking save & dispense opens a popup window with the prescription and then a print dialog. Why? Its in-house. We don;t need to print a prescription for the patient at this point.

Performing the pos checkout after dispensing, on save I get “This patient has no activity!” I’m guessing because we don’t have a regular encounter open? Data gets entered into the billing table, but doesn’t show up in any financial reports.

So, this still doesn’t seem to be exactly working. I’m going to go get some sleep now. I hope someone can set me straight in the am.

Thanks for putting up with all of this.

sunsetsystems wrote on Wednesday, June 03, 2009:

Mixing in-house product sales with insurance-billable items in the same encounter is currently not supported.  What I suggest is creating a separate encounter for each.  Otherwise the code will need some work.

Also you don’t want to use prescriptions for anything other than writing prescriptions.  Enter product sales into the Fee Sheet instead.

Rod
www.sunsetsystems.com

fred0 wrote on Wednesday, June 03, 2009:

Rod,

Thanks for that advice. I’ve now done a few tests based on using separate encounters and found some issues with it.

First, if I create 2 encounters, 1 for products sales and 1 for insurance billable, the checkout form only sees the insurance billable encounter even though both are unpaid and even if I have the product encounter as the active encounter. Tried creating one before the other (both ways) to the same result.

Second, prior to doing checkout on a product encounter, the product items do not show in the encounter list view the way codes do, making it difficult to know what that encounter is for. They do appear after checkout is compete though along with TAX and COPAY.

Third, once checkout is compete on a product sale, it appears in the Billing view with the error "Note: This code was not entered by an authorized user. Only authorized codes may be uploaded to the Open Medical Billing Network for processing. If you wish to upload these codes, please select an authorized user here."

The first problem alone causes the entire workflow to fail and makes product sale checkout nearly impossible, especially when the global auto_create_new_encounters is set to true. If the exam encounter is auto-created (something my users really like) and then used by the physician to do the exam, then that encounter has to be used for insurance coding. If I then create another encounter for a product sale (which would only come after the exam as the product is chosen during the exam) then the checkout form will not show the product sale encounter.
The only way this works is be sure to create only the product encounter, process the pos checkout, then create the exam encounter.
I can’t imagine that working for anyone and it means there is no encounter for the physician to use during the exam.

To my mind, the work flow should be like my suggestion at the end of the first post above.
I don’t have any problem with a product sale being a separate encounter, but POS Checkout should be a single activity that shows all open billable items and allows the user to select which ones are being paid for. Along with that, payments that are not actually Co-Pays should be not be recorded as such. That’s just confusing when doing financial reports.

fred0 wrote on Wednesday, June 03, 2009:

I should add that if this is to be re-worked, then adding product sales and insurance items to the same encounter would be an even better and more streamlined workflow. One should only need to create a separate encounter if a patient/client is making a purchase without an exam appointment.

sunsetsystems wrote on Wednesday, June 03, 2009:

OK.  Looks like someone will have to do some work before it will do what you want.  Email me privately if you’d like that to be me.

Rod
www.sunsetsystems.com