CMS1500 - Box 31

  • mike-h30

    mike-h30 - 2011-06-28

    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.


    P.S.  Nice write up Idea Man Joe and Tony!! I have been referring to your billing setup documentation during my process.

  • Tony McCormick

    Tony McCormick - 2011-06-28

    Sig on file is sufficient as provider name and date are already on the form.  And your welcome re: the FAQ and stuff!

  • mike-h30

    mike-h30 - 2011-06-28

    Thanks Tony!!

  • Anonymous - 2013-08-28

    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?

    Last edit: Anonymous 2013-08-28
  • Tony McCormick

    Tony McCormick - 2013-08-28

    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 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());


    • Kevin Yeh

      Kevin Yeh - 2013-09-08

      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.

      • Tony McCormick

        Tony McCormick - 2013-09-09

        It should really be a option in the insurance company data record, I think
        On Sep 8, 2013 9:53 AM, "Kevin Yeh" 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

        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 31

        Sent from because you indicated interest in

        To unsubscribe from further messages, please visit

        • Kevin Yeh

          Kevin Yeh - 2013-09-09

          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 - 2013-09-09

            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.

  • Anonymous - 2013-08-28

    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!

    Last edit: Anonymous 2013-08-28
  • fsgl

    fsgl - 2013-08-28

    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 - 2013-08-28

    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

    fsgl - 2013-08-28

    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.

    Last edit: fsgl 2013-08-28
  • Anonymous - 2013-08-29

    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

    fsgl - 2013-08-29

    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.

    Last edit: fsgl 2013-08-29
  • Anonymous - 2013-08-29

    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

    fsgl - 2013-08-29

    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 - 2013-08-29

    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

    fsgl - 2013-08-29


  • fsgl

    fsgl - 2013-09-01

    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?

    Last edit: fsgl 2013-09-01

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks