mike-h30 wrote on Tuesday, June 28, 2011:
I noticed that when the CMS1500 is generated in OpenEMR, Box 31 just has “SIGNATURE ON FILE.” Is that sufficient for payment?
Our current billing software (EZ-Claim) would also print the “provider’s name” and “date.” I am in the process of converting our billing to OpenEMR. Unfortunately we still have a few paper claims to submit.
Mike
P.S. Nice write up Idea Man Joe and Tony!! I have been referring to your billing setup documentation during my process.
tmccormi wrote on Tuesday, June 28, 2011:
Sig on file is sufficient as provider name and date are already on the form. And your welcome re: the FAQ and stuff!
-Tony
mike-h30 wrote on Tuesday, June 28, 2011:
Thanks Tony!!
anonymous wrote on Wednesday, August 28, 2013:
I had an adjuster call today and say they cannot process our claim without a physical signature, or at the very least, the physician’s name printed in box 31. First time I’ve ever had a bill denied for that reason.
Is OpenEMR supposed to generate the rendering physician’s name in box 24, row J? Our NPI number is there, but the provider name is not above it. Is that by design? If not, how difficult would it be to call the rendering physician to that box?
tmccormi wrote on Wednesday, August 28, 2013:
There are a few payors that require this. We have made minor changes to 1500 off and on to support that feature, usually you have to put an IF BLOCK for the payor ID or similar so you don’t break the ones that need NPI. This should really be a by payor configuration. Maybe Kevin can add that in his CMS 1500 updates project that he is working on.
In the mean time the lines to change in gen_hcfa_1500.inc.php start at 567, you can uncomment the lines that print the privider name.
// 31. Signature of Physician or Supplier
// FreeB printed the rendering provider's name and the current date here,
// but according to my instructions it must be a real signature and date,
// or else "Signature on File" or "SOF".
put_hcfa(60, 1, 20, 'Signature on File');
//
// $tmp = $claim->providerFirstName();
// if ($claim->providerMiddleName()) $tmp .= ' ' . substr($claim- >providerMiddleName(),0,1);
// put_hcfa(60, 1, 20, $tmp . ' ' . $claim->providerLastName());
–Tony
anonymous wrote on Wednesday, August 28, 2013:
Great. That’s just what I was looking for. After hundreds of claims submitted to State Farm, this is the first time an adjuster flat out denied payment because the doctor’s name wasn’t on the form. I suppose the NPI number wasn’t sufficient for her.
Either way, adding the provider’s name in box 31 won’t hurt. Appreciate the info!
fsgl wrote on Wednesday, August 28, 2013:
Medicare is a bit of a stickler about the CMS 1500 form. Because only one CMS 1500 is used for all insurers in OpenEMR, adding the rendering physician’s name on top of the NPI in box 24J may make Medicare unhappy.
anonymous wrote on Wednesday, August 28, 2013:
I think adding the physician’s name in box 31 should suffice. Antoher thing I’ve noticed is that when the doctor’s name is called in a form or report, there is no option to add the medical credentials. It only shows first/middle/last. Am I missing something here or is that a feature that has yet to be added? I’d be happy to sponsor if the latter.
fsgl wrote on Wednesday, August 28, 2013:
At our local Medicare and Blue Shield the paper claim is scanned and software is used to check if the claim has all the information in the right places and then to process the claim for payment. Any problem with the claim would be communicated to our office via a form letter about the missing information or a denial code on the EOB. Human hands never touch the claim. I think the other carriers have the same automated process.
Very unusual that a real live person from State Farm called about Box 31.
How about appending “M.D.” after the surname in Administration->Users? That way you can save the moola for Kevin’s next project, an automated testing suite.
anonymous wrote on Thursday, August 29, 2013:
I initially tried that, but it looked kinda off in the places where the surname is called first (e.g. calendar, referrals, fee sheet). In my opinion, the provider names should be called in order (i.e. first/middle/last). It wouldn’t be any harder to find a name alphabetically and would solve the issue with credentials, as you suggested, by appending to the surname. Thoughts?
fsgl wrote on Thursday, August 29, 2013:
Just experimented on Sherwin’s 4.1.2 Demo.
Calendar seems to be fine.
The Referral Form is a bit quirky. The “referrer” is F,M,S while the “referred to” is S,F,M.
The Fee Sheet has S,F,M.
Based on the appearance of the Calendar and the Referral Form, it should be possible to change the codes to F,M,S for all modules. The developers will have to tell you where to look.
In China and Japan, family names always go first, which is more logical like year/month/day. Not literate in either simplified or traditional Chinese, thus cannot check it out in those versions of 4.1.2.
anonymous wrote on Thursday, August 29, 2013:
Looks like the middle name (or initial) is being omitted altogether. I’m not seeing it called anywhere. I’d like to go through the codebase and make the naming convention more consistent. Any interest in having this contributed back to the project?
fsgl wrote on Thursday, August 29, 2013:
Uncertain about the name order convention in Africa.
Because only 25% of the downloads are from the United States, project wide changes to suit Americans may not serve our international colleagues well. An alternative is to have in Globals->Locale, a drop down menu for S,F,M or F,M,S in a new “Name Display Format” preference.
If the preference item is not possible, please do let us know where to change the codes to get F,M,S.
In Users, there is a field for “Middle Name”, but it does not display; therefore it must be inserted in “First Name”.
anonymous wrote on Thursday, August 29, 2013:
Option in Globals > Locale sounds about right. I just hate making custom changes locally. Seems a waste to spend time tinkering around without contributing. I’ll be spending some time on this during the long weekend.
fsgl wrote on Thursday, August 29, 2013:
Wunderbar!
fsgl wrote on Sunday, September 01, 2013:
I want to keep “signature on file” in Box 31 and also to have the current date beneath it. Inserting the code into lines 583 and 584 gives YYYY/MM/DD despite the change in Globals/Locale to MM/DD/YYYY (which probably is unrelated). Changing the serviceDate to currentDate gave a blank screen.
How does one get the MM/DD/YY format as the display in Box 24a. (blank spaces in between) using the current date?
yehster wrote on Sunday, September 08, 2013:
A global option to put “Signature on File” as currently implemented, leave the field blank so a pen/ink signature can be added later, or print the provider’s info should not be too hard and ought to handle the most common cases.
If a given office needs to deal with more than one of these formats for different payers, they will have to switch modes between batches.
tmccormi wrote on Monday, September 09, 2013:
It should really be a option in the insurance company data record, I think
On Sep 8, 2013 9:53 AM, “Kevin Yeh” yehster@users.sf.net wrote:
A global option to put “Signature on File” as currently implemented, leave
the field blank so a pen/ink signature can be added later, or print the
provider’s info should not be too hard and ought to handle the most common
cases.If a given office needs to deal with more than one of these formats for
different payers, they will have to switch modes between batches.CMS1500 - Box 31https://sourceforge.net/p/openemr/discussion/202504/thread/3cc52efc/?limit=25#1a31/1b29
Sent from sourceforge.net because you indicated interest in
OpenEMR / Discussion / OpenEMR UsersTo unsubscribe from further messages, please visit
SourceForge.net: Log In to SourceForge.net
yehster wrote on Monday, September 09, 2013:
I agree with you, but I’m lazy. It’s much easier to add a global than a field to the insurance company data record from programming, testing and documentation standpoints.
A global will at least be better than hard coding it. Frankie, does your group submit paper claims to more than one adjuster?
anonymous wrote on Monday, September 09, 2013:
We primarily deal with auto claims, so every patient has a different adjuster. A global option would work perfectly for our clinic, but I can see how an insurer specific option would make sense for those that may need to cater to specific regulations.