So are you trying to get a fix for your client who is on, looks like 4.2.2 or 5.0?
The purpose of this public discussion to fix an issue that is in the current code and the upcoming 5.0.2. Also, I am trying to be all inclusive.
What we need is a new dialog to replace current okay/cancel alert. It would include new option to do a dry run and maybe option to clear billed flag.
The existing clear button is meant to reset payer type(primary,sec etc) and set the claim as billed so we need to leave it be.
I could do a synchronous dialog with dlgopen but that would restrict any backports prior to 501 so a custom to billing will be needed.
This is best solution imo otherwise changing the Clear to reset billed will confuse users. There has to be a good reason original design has clear this way ie marking claim as billed but not billing!
maybe not 
also clicking cancel should cancel the download of the file
Meaning a good reason for the clear button?
Do you mean for new dialog?
Stephen, that makes sense because the file in not going to be looked at in ātest modeā. It is a waste of space to download a file that will not be used. However, that just causes more thinking.
Jerry, if you think it is best to leave the current system in place and create a new path for claim scrubbing feature. I can agree with that so the original function doesnāt get destroyed.
More thinking, I am heading back to 3.x to see what it was back then. I know I remember it working somewhere in the past.
If Jerry is going to build a better dialog box verses the current java popup. We are all in for a treat!
sorry, clear button is useful
if cancel just worked as expected no need for new dialog imo
Cancel does work way is is intended which is to continue on with bill process. think of it as cancelling clearā¦
maybe itās allergies but starting to feel 
shouldnāt cancel give user the ability to abort a mistaken click without any continuation?
in code this is a confirm box or yes/no but confirm only has okay/cancel so the dialog is really meant to ask Do You Want to Clear after billing is process. yes to clear no to continueā¦
ok, thank you
so continue processing should mean reset to unbilled status?
nope, continue just continues the selected billing option (x12,hcfa download etc) which then sets the billed flag. The only thing that ever resets billed flag is reopen claim button.
Iām still trying to figure out why we have clear to reset payer type back to primary. Why would you send a claim and turn around and reset payer type? Maybe prevent advance to secondary billing but that is in posting, I think!!!
cancel should just cancel, if need to view log and then correct well the claims are still selected in the billing manager and can be regenerated without having to filter
you probably know that it needs to still be pending insurance
and to do that weād need a new dialog and not a confirm because if we cancel from confirm it would also stop the batch(the way it is written now).
really believe that cancel should stop the batch but it isnāt, what part of the code is this?
billing report L-660 is one instance and L-342 is the function.
The confirm holds up the form submit.
1 Like
Ok, @sjpadgett, the cancel should stop the processing of the batch. The purpose to cancel is not to produce a batch. It is to produce the data for the log so claims can be adjusted before the real batch file is generated by selecting OK. I agree this should be clearer and a better dialog box is needed to convey the correct logical thinking. The java box canāt do it.
The way iāve explained the function of the batch confirm prompt is the way it has always worked. I brought this issue up 5 years ago where it worked the same way. Cancel is very misleading and is why I added the Click Okay to Clear or Cancel to continue batch to help clarify. If we use cancel the way you suggest then we would have to prevent the form from being submitted which is how the x12/835/HCFA are generated along with the logs.
To do this the way I think you guys want this to work, we need to create another flag to pass to the form process routine to not dispose of the batch to download or send electronically etc. and either leave claim status and billed status as is currently or reset. This way the logs will be generated for review and the claim will be left alone for disposal later.
Now OpenEMR has humbled me in the recent past but iām pretty sure I have this correct. If not, well, I needed the typing practice at any rate
@sjpadgett much apologies.
I am not disputing how it currently works. I submit to your explanation of the way it works.
I am only being an advocate for those users that are chewing on my ear about when they click cancel the encounters that are on the screen disappear and they are expecting them to stay.
If you can make the encounters stay on the screen when cancel is selected, they will all be happy.