Menu

#3469 With consultation_fax_enabled=true, the billing_no is printed on consult but should be ohip_no

RELEASE_12_1
closed-fixed
nobody
None
4
2014-08-22
2014-08-21
David Grant
No

With consultation_fax_enabled=true, the billing_no is printed in brackets next to the referring doctor's name. What really should show up here is the ohip_no column from the provider table, not the billing_no. In most cases billing_no and ohip_no are the same but for cases like locums, they are different (in locum case billing_no is the billing number of the doctor getting paid). What needs to be shown next to a doctor's name on the bottom of a consult is the ohip_no. I think this change should be made in 12.x and master.

Long thread on mailing list about this here: https://sourceforge.net/p/oscarmcmaster/mailman/message/32738235/
There seems to be some consensus that switching to ohip_no will not cause any problem and that this is a bug and not intentional.

It's like a 2-line code change, so I'd like to try to commit this myself in order to become more familiar with the process.

Related

Bugs: #3469
Bugs: #3843

Discussion

  • SBek

    SBek - 2014-08-21

    Replicated in both Release 12_1 (build# 422) and Master (build# 2134)

     
  • SBek

    SBek - 2014-08-21
    • status: open --> open-accepted
     
  • SBek

    SBek - 2014-08-21

    Hi David,

    There is a bug [#2505] filed a while ago. Please take a look and advice if it sounds relevant to what you've reported.

     

    Related

    Bugs: #2505

  • David Grant

    David Grant - 2014-08-21

    Good find! Yes, you are right that is related. I think #2505 is referring the "vanilla" consults and yes this is a problem. In my clients' practice they are putting the MSP/OHIP number in their last name as a hack, so that it shows up on the consult.

    This bug is referring to the all-in-one PDF (including eDocs and labs) that gets created with the consultation_fax_enabled=true option enabled. I could probably fix 2505 after as well.

     
  • SBek

    SBek - 2014-08-22
     
  • SBek

    SBek - 2014-08-22
    • status: open-accepted --> open-fixed
     
  • SBek

    SBek - 2014-08-22

    Retested R12_1 commit: https://source.oscartools.org:8080/#/c/10826/-> issue has been resolved. Please see attached.

    This issue is also present on Master (build# 2134). Could you commit your fix to Trunk as well?

     
    • Marc Dumontier

      Marc Dumontier - 2014-08-22

      i committed a cherry pick
      https://source.oscartools.org:8080/10833

      On Fri, Aug 22, 2014 at 10:06 AM, Suni Bek sunibek@users.sf.net wrote:

      Retested R12_1 commit: https://source.oscartools.org:8080/#/c/10826/->
      issue has been resolved. Please see attached.

      This issue is also present on Master (build# 2134). Could you commit your
      fix to Trunk as well?

      Attachment: R12_1 ohip_no_fix.png (130.0 kB; image/png)

      Status: open-fixed
      Group: RELEASE_12_1
      Created: Thu Aug 21, 2014 06:18 AM UTC by David Grant
      Last Updated: Fri Aug 22, 2014 01:34 PM UTC
      Owner: nobody

      With consultation_fax_enabled=true, the billing_no is printed in brackets
      next to the referring doctor's name. What really should show up here is the
      ohip_no column from the provider table, not the billing_no. In most cases
      billing_no and ohip_no are the same but for cases like locums, they are
      different (in locum case billing_no is the billing number of the doctor
      getting paid). What needs to be shown next to a doctor's name on the bottom
      of a consult is the ohip_no. I think this change should be made in 12.x and
      master.

      Long thread on mailing list about this here:
      https://sourceforge.net/p/oscarmcmaster/mailman/message/32738235/
      There seems to be some consensus that switching to ohip_no will not cause
      any problem and that this is a bug and not intentional.

      It's like a 2-line code change, so I'd like to try to commit this myself
      in order to become more familiar with the process.


      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/oscarmcmaster/bugs/3469/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/

      --
      Marc Dumontier
      519-584-5601
      http://oscardevel.com/wordpress/
      http://www.oscarmcmaster.org

       

      Related

      Bugs: #3469

  • SBek

    SBek - 2014-08-22

    Re-tested Master commit: https://source.oscartools.org:8080/10833 -> issue has been resolved. Leave this one open while Master has been reviewed.

     
  • SBek

    SBek - 2014-08-22
    • status: open-fixed --> closed-fixed
     
Auth0 Logo