One idea to address the crowding is to change the fee sheet problem list to a drop down that works like the justification of procedure codes with diagnosis codes, except the selected problems listed below and a “clear” link (not a selection item). If that is done, the diagnosis code could possibly be prepended to the problem title, which would just be helpful. The insurance selector could go above the problem list, with the primary as the default, like the billing frame.
For a family practice clinic, I only use Misc Billing Options form to enter authorization numbers, but I use fee sheet heavily along with the charges menu because it requires fewer clicks for justification of procedure codes!
Perhaps “claim” would be a better term to work off of? Our office handles primarily motor vehicle accidents and workers’ compensation claims so we’ve had to do some customization to accommodate our billing needs.
Firstly, we added a custom field under demographics to display the date of injury, which is very important for filing on the basis of a claim. This date of loss will then be referenced to populate the Onset/hosp. date field on the Patient Encounter Form, which corresponds with box 14 on HICF Form 1500. Claim payment will be denied if this field is not populated on the claim form, so it is of great importance for timely payment.
Secondly, we have to be cautious of the meaning of “Policy Number” and “Group Number” under the insurance section. In the case of a specific accident (or claim), the Policy Number field reflects the Claim Number (Insured’s ID Number in box 1a on HICF 1500) and the Group Number field reflects the Policy Number (Policy, Group or FECA Number in box 11 on HICF 1500). It can get a bit confusing seeing as the term Policy Number is used differently for accident claims and major medical visits. At one time I considered playing with the code to reflect these naming discrepancies, but decided not to on the basis that we may one day accept major medical insurance as a secondary payer.
Another issue that tends to generate non-payment is failing to populate Box 10 on HICF Form 1500, which signifies that the visit is based on an accident claim. Being that this must be done for each encounter, it has been overlooked from time to time, causing payemnt to be denied due to lacking information. Insurers will find ANY reason to deny payment. Perhaps it would be more useful to tie in Box 10 at the claim or “case” level, that way it will be auto-populated when an encounter is created?
I do agree that the fee sheet should be for coding purposes only with claim (or case) information tied into the main Demographics screen.
Dusting off an old thread to discuss development with this issue:
Chatted with someone today. Similar case. Auto insurance needs to act as primary concurrent to ‘real’ primary.
He used the term “Case”. It seems to be standard terminology.
He mentioned that deciding it was a Case should be selected in the Encounter Form, like “Issues”.
This should trigger the Billing Manager to recognize this as a special case and take appropriate action. Naturally displaying a billing note in billing manager is desirable at this point (commit exists).
Most other billing software is aware of this situation.
My approach opinion:
Flag the encounter as a Case in the encounter.
Don’t touch the billing table.
Add “Special Case Insurance” or “Liability Claims” or “Special Claims” insurance category to insurance_data, and add the UI to the dashboard (maybe a global toggle as well).
Add Billing Manager handling/notes.
Is that a good approach? Any concerns? We are getting on this item immediately.
When maximum benefits of accident insurance are exhausted the primary health insurance becomes secondary which would make billing difficult without denial in billing table.
we have this same issue with a FQHC (Federally qualified Health Clinic) and worker’s comp clinics. There are is a clear requirement to be able to bill a specific “primary” for a specific case (or set of encounters).
I have code for wrapping encounters inside a ‘Case’. Adding a insurance type to the insurance_data table for ‘Case/Encounter’ would be a good start.
The billing process could first see if the encounter has a special payor, that has not been billed and marked Done, and use that one, if not fall back to normal Ins1.
the model in the current payment posting allows for “Done with Ins1” could just add a level for “Done with SpecIns”.
Another refinement might be to drop the hard coded designations of Primary, Secondary, Tertiary and just have N+payors. The payor chain 1,2,3 (if any) could be just picked at the time of billing, with some defaults. Each Ins_data record could have a pointer to it’s secondary. 1->2 2->3, 4->1 (where 4 is special case)
Also.
High time the ins data dialog was cleaned up, preferable made into a layout based and include a real user settable 'Termination Date" instead of presumed to be effective until the next insurance record is entered.