My pleasure. Thanks for the speedy support!
thank you @sjpadgett, itās an oversight, openemr/billing.inc at rel-500 Ā· stephenwaite/openemr Ā· GitHub
I remember this working in 4.2.x and I have been looking through the code. I am not sure when this stopped working. But it is good someone brought this up.
@sjpadgett thanks for jumping in this pond.
@stephenwaite what are your thoughts on this issue?
I feel a little stupid to come back with the next question (and I am aware that I am somewhat hijacking the thread), but ā¦
According to the Billing wiki and the video my newly found Billing Manager page should have a link to EOBs, producing exactly the kind of invoice I need. Alas this link is gone. And this time itās not just my own botched installation, but itās also absent in the official demo.
Any hints, where it went, or how to activate it?
Cheers guys!
Raimund
take this :parachute, fees->posting payments
Aaah! Thanks! was too confused to realize that the Posting form is (almost) the same as the former EOB form. Billing terminology and process in the US seem to be VERY different from Europe.
Still I feel the urge to share my newfound wisdom about the billing process by updating the respective wiki pages. (A lot of the 5.0 Wiki actually refers to earlier versions). Would you guys welcome that or would you rather not have anyone mess with the wiki who only has half a clue?
most welcome, OK. great. will do in 2 or 3 days, when I am back home!
Okay, bottom line is that this behavior has always been this way(at least to 4.2.2). Whenever a hcfa 1500, ub04 or x12 is generated, claim status and bill process is set to 2. By the nature of status set to 2, code will automatically set the billed flag to 1.
This makes sense that if you click cancel or okay you are still processing a claim which in tern needs to identify that the claim has been sent(or at least generated), otherwise, why send the claim?
I tried to make this clearer when I added the additional prompt instruction that cancel continued the claim processing and okay cleared the claim afterwards. Iām unsure what clear actually does but I believe it will clear the payer type and leave claim status and bill process in current state.
So in the end, we want this behavior otherwise we would have to leave it to the user to mark a claim as billed. I donāt know that we would want to add a capability for the user to clear a claims billed status once set but iām not in the billing business and would require a consensus to change this behavior, imo.
Also, if user needs to resend or get a copy of report, theyāll need to search as billed claim then do the deed.
Hope this helps!
oh sorry, are we saying that if payer type is cleared then billed should also be reset? not a good idea either because, if billed flag has been set it is only way to know the claim has previously been submitted unless all the claim versions are reported as historyā¦
The whole reason this has come up is because the only way to use the claim scrubbing feature is after generating a claim. So, the logic was generate the claim without marking it as billed so that the claim scrubber could do its job and then the user can look at the log to see what needs to be adjusted in claim before it is generated a second time to be sent and marked as billed by the system.
This is the behaviour that the users are expecting. This is the behaviour the system says it has but as you have uncovered is not functioning as intended. Is it possible to make this function as intended or @stephenwaite is there another way to have the claim scrubber work?
Hi Sherwin,
Okay, I think I get it now. By scrubber do you mean the clear function? It wouldnāt be that hard to clear the billrd flag if you guys decide thatās the way to go.
Hi Jerry,
No I mean the log function (claim scrubber would be more inline with what the industry calls it). The view log will not populate until the claims are passed through. Then users can see what is missing or needs address.
Just for clarity, I am adding this image to the thread.
Yes, I like the words trial run before the actual batch goes out.
Yep this makes perfect sense when put that way. Something like a trial run or a way to revert to previous billing state.
1 Like
I have to think about this for a bit to figure out the easiest or most unobtrusive way to do something like this. Unless you want to take a whack at it.
I have been whacking and have not stumbled upon a solution yet. Let us both keep whacking and thinking. I will run my solution by you once I have thought of one.
Works for me. Maybe list out what you think the workflow would be and weāll take it from thereā¦
Question, is the bill_process.php solely responsible for marking the entry billed?
No, bill process calls BillingUtilities.php and around L-1494 based on claim status from updateClaim will set the billed flag. eg BillingUtilities::updateClaim(false, $patient_id, $encounter, - 1, - 1, 2, 2, $bat_filename)). 2 is status.
buttons are defined in billing_report.php
Ok for me in the older codebase that would be billing.inc which is now converted to BillingUtilities.
$ar['HiddenMarkAsCleared'])
So, to keep this as simple and clean as possible, canāt we pass HiddenMarkAsCleared into the billing utilities? Then execute an if statement there like
if (isset($ar['HiddenMarkAsCleared']) && $ar['HiddenMarkAsCleared'] == 'yes') {