Let us start this discussion with stated objectives for the code development to make sure we meet those objectives. This way our OpenEMR SDLC will also be refined.
Please add your objectives to this so that we can figure out what everyone wants to achieve.
Here are a couple of objectives:
1. To enable the choice of selecting different insurance as primary for different encounters.
2. To make sure that the insurance are selected for each encounter as opposed to being called from the demographics.
It would not be hard to add an optional case record. The details TBD, but would have related insurance records, either chosen form existing or added for the purpose of the CASE. Then the encounter selector could be attached to a case and inherit the insurance info. For encounter specific insurance it’s just a case with one encounter. Far more flexible this way as the contents of the case table can expand as needed with out effecting it use at the encounter level.
You will have to add (automagically) tabs in the insurance data widget to show CASEID# or similar when a new case insurance record is created
-Tony
We usually see a child with managed care medi-cal who has, for example, Blue Cross with a certain medical group IPA. Now we see them for well visit. In order to get reimbursement for shots or other well visit services. We need to bill Blue Cross directly. In our system, we set the medical group IPA as primary, Blue Cross as secondary. Currently, when we do batch billing, sometimes we forget to select secondary insurance. So, when the EOB statement comes back, we realize that we have made a mistake.
Therefore to avoid the obvious mistake. I suggest that we should have the option in the fee sheet to select insurance option as we have in the billing section. So when we do the batch billing (even we have amnesia) the billing will come out correctly. Just a thought.
What exactly is a “case”? If it’s a medical problem, remember we have “issues” to represent those.
While issues is kind of close to a case, it’s not really the same thing, but it could be exanded to handle it. The difference is is that a “case” in my experience has to do with who is paying for the series of encounters, not WHAT the encounter is about exactly. That said, we could add an issue type called CASE, and allow payor information links as described. The shared nature of the issue program might make it more complicated than just creating a case table and dialog though.
Different visits (encounters) can easily have different insurance, even when they are related. Insurance expires and changes at arbitrary times.
While that is true, it is not intuitive to the user to change the primary insurance company back and forth and there is not easy way to see the process, nor does it support overlapping dates. ie: two primary one for *this->‘case/encounter’ and a different one for *that->encounter which occurred maybe on the same day even.
I agree whole heartedly with the other 4 comments.
-Tony
Hi,
The examples I have seen of using “cases” are in Acupuncture clinics where need to keep claims separate for accident claims and insurance claims on the same patient.
-brady OpenEMR
The insurance_data table includes an effective date and a priority - primary, secondary, tertiary. For any given date and patient, only one of each priority is active.
Sounds like an additional attribute for “usage” may be desirable (“case” seems confusing as it means something else in a clinical context). In this way multiple insurances of each priority could be active.
The New Encounter form could be enhanced to include a Usage selector. Only usages active for the current patient as of the encounter date would be shown.
There are plenty more details to work out but this is one possible approach to start with.
Case is still the right word in my opinion. Need to hear from some more users on the topic of what to call things.
The insurance table needs effective date AND term date. Right now the assumption is that term date is the effective date of the next insco record, which is not true if there is a gap in coverage.
What attributes would ‘usage’ have? That might help clarify what you have in mind. Part of this, I presume, would be priority by usage…
You can get around the lack of termination date by creating a following entry with insurance “Unassigned”. But I agree that a more explicit method is better.
“Usage” could be a normal list in list_options. It might have entries like “Default”, “Auto accident”, “Work injury”, etc.
I think the ability to select between primary, secondary and tertiary in the encounter form like the Fee sheet should do the trick, and default should always be primary. It will give us more flexibility when doing billing batch. Right now, I have to go to the billing menu to be able to select secondary for tertiary insurance for billing. It is such a hassle.
The issue here is that we don’t always remember to bill for secondary or tertiary when doing billing batch!
From what I am told by my billers is that it is better to give the option to select the insurances in the fee sheet because the doctors dont necessarily know the details of the billing. So I think it is better to do the following
Show the default insurances in the fee sheet.
Ability to change the insurances in the appropriate fields like primary secondary and tertiary
Change the claims file.
I would be interested to know your success in secondary billing. I am concerned that the era processing has too many unhandled or incorrectly handled adjustments so that the prior payment information needed for secondary billing is just not reliable. Do you correct everything beforehand?
In my case. I am not doing secondary billing. It just happens that I need to choose secondary insurance for primary billing. Therefore, I would not know how it would handle secondary billing!.
ERA processing and mechanics of secondary billing are definitely worthy of discussion but are a different topic, suggest y’all start a new thread for that.
The fundamental issue for doing this correctly, isn’t so much which screen (fee sheet vs. encounter) the required information is captured on, but rather how it is represented in the database.
A well designed representation would allow users to easily view and update the information at any point in the workflow.
For example, the receptionist might make note of the need to bill a different insurance at the time the patient checks in it might be the billing person that ultimately notices.
Also, we still haven’t figured out the correct place to capture the details additional primary insurance carriers. The fee sheet is definitely *NOT* the right place for that. Although maybe the code which you said you were going to release 6 months ago for practice management covers that.
I have to disagree. Fee sheet captures all the billing details. Especially for insurance to be “encounter specific”, it makes sense to have billing insurance information on that page also!
Would be nice to see some clinic manager types weighing in here. The Fee Sheet is about “coding” the visit and has so far been mostly independent of insurance. Not to mention that it’s already very crowded.
There’s already a separate form (Misc Billing Options) for encounter-specific insurance stuff. Perhaps that needs to be revisited and made more accessible and user-friendly.