The spirit of the QHR ideas portal is to collect ideas and feedback from our users for integrations, enhancements, and new features.
We want to hear from you, and encourage you to submit, comment, and vote!
Please note that this site is not regularly monitored, and that there may be a delay in response to your submissions.
QHR reserves the right to choose what is built into the application, and it is the intention of QHR to build the software to meet the needs of the marketplace.
User Resources:
Accuro Learning Academy, our eLearning platform (reach out to Client Services for your sign-up code)
For further support, please reach out to Accuro Client Services:
1-866-729-8889
Accuro Menu > Help > Send Feedback
Interested in providing regular feedback on product ideas and designs that are team is exploring? Send an email with your Name, Email, Specialty and Province to uxresearch@qhrtech.com with the subject "Interested in participating in research".
I support the idea of making the previous health card number (PHN) easily viewable in the Patient section, but I’d like to propose an additional use case that goes beyond OHIP version codes.
Currently, if a patient initially presents with an out-of-province health card (e.g., a BC Care Card), Accuro shows their appointment history and billing under OHIP—even though those claims are actually paid through the Reciprocal Medical Billing (RMB) program. If the patient later switches to an Ontario health card, there’s no clear way for providers to identify when that transition occurred or which OHIP claims were submitted under RMB versus the Ontario health care program.
This lack of visibility creates a challenge when determining eligibility for virtual care billing. OHIP rules state that comprehensive virtual care is only payable if there is an existing physician-patient relationship—defined by a prior in-person appointment or a specialist video consultation within the past two years. Without a clear record of when the patient switched provinces, providers may struggle to confirm whether a qualifying in-person visit occurred under Ontario coverage or RMB.
The refusal message sent from OHIP already includes the invalid version code. For example:
The error received from OHIP is:
Mismatched Version Code (AB)
This means AB was the "old" version code that OHIP rejected. So if the current version code is anything other than AB, you know it has been updated to a newer version code.
When the error from OHIP is:
Mismatched Version Code ( )
This means the "old" version code was blank, and one needs to be filled in with the resubmission.
It would not be common workflow to check the audit logs to find an old version code when a claim is rejected. Could you let us know if this information helps you more easily identify the wrong version code so that you may resubmit the rejection quickly?