What we build for Ontario clinics around medical billing
OHIP claims get rejected, uninsured-services revenue leaks out, and EMR billing modules only do part of the job. A practical read on what custom development actually adds, and where we slot in for clinics that need more than their EMR.
The numbers on Ontario medical billing in 2024-2025 are not subtle. An OMA survey of 2,500+ physicians found that 90% had claims rejected in 2024. Across the system, more than 1.16 million cases per year are tied up in manual review, with physicians waiting months or sometimes years to get paid. The average doctor forfeits roughly 20-50% of $25,000-$30,000 of monthly billings to denied stale-dated claims that sailed past OHIP’s 3-month resubmission window.
That’s the macro picture. The clinic-level picture is usually some combination of: rejection codes nobody on staff understands (EQP, AD9, A2A, ARF), an aging-AR report nobody reads, and a fee schedule that updated last quarter and broke a few of the office’s saved bill templates.
This is a post about what we actually build for Ontario clinics around billing. It assumes you already have an EMR and a basic billing workflow; we’re describing what custom development adds when those tools start to break down.
What the EMR billing module does well
The big three EMRs in Ontario hold most of the market: TELUS Health (PS Suite, Med Access, CHR) at roughly 42%, QHR/Accuro at 26%, WELL Health (OSCAR Pro, Juno) at 24%. Most of them ship a billing module that handles the basics: encounter coding, MCEDT submission, remittance advice import, basic AR reporting.
For a small family practice with one or two providers, the built-in module is often enough. We do not recommend ripping out a working EMR billing module to build a custom one. That’s not where the value is.
What the EMR billing module does not do well
The gaps that drive most of our clinic engagements:
- Multi-provider, multi-location reconciliation. Once a clinic has 4+ providers across 2+ locations, the per-provider P&L becomes hard to assemble from the EMR’s reports. Owners end up reconciling in spreadsheets monthly.
- Real-time rejection visibility. Most EMRs surface rejected claims in a queue you have to remember to check. By the time someone notices, two months have already burned off the 3-month submission clock.
- Uninsured-services billing. OHIP doesn’t cover sick notes, third-party medicals, cosmetic consults, sports-medicine work, telehealth blocks for non-Ontario residents, and a long list of others. The OMA’s 2026 uninsured-services schedule (multiplier 2.90x of OHIP) is a real revenue line that most EMRs treat as an afterthought.
- Patient-facing payment. Collecting a $50 sick-note fee at the front desk is friction. Sending an emailed Stripe payment link works much better, and almost no EMR does this natively.
- Block-fee program management. Clinics offering annual block fees for uninsured services need patient sign-up flows, year-over-year renewal, partial-year prorating, and reporting. The EMR doesn’t do this; PatientSERV / WELLSTAR’s offering does some of it but isn’t right for every practice.
- Automated reminders for stale-dated risk. A claim that was rejected on day 14 doesn’t auto-poke you on day 75 telling you it’s about to die. Custom dashboards do.
What we actually build for clinics
When a clinic comes to us with a billing problem, we do not pitch them on a new EMR. The work is usually one or more of these six things, sitting beside whatever EMR they already use:
1. A rejection-and-AR dashboard that reads from MCEDT. Pulls remittance advice files daily, flags every rejection by code with a plain-English explanation and a suggested fix, ages claims toward the 3-month deadline with email/SMS escalations to whichever staffer owns the queue. This single dashboard typically pays for itself within a quarter by recovering claims that would otherwise stale-date.
2. A patient billing portal for uninsured services. Patient gets a link, sees the line items, pays via Stripe (Visa/MC/Amex/Interac e-Transfer through Stripe’s CA rails), gets a receipt. For block-fee programs we add subscription billing with renewal reminders. We’ve covered the PHIPA constraints around patient-facing portals separately. The short version is that PHI itself doesn’t go through Stripe; the portal stores only what’s needed for billing purposes, with a clean separation from the clinical record.
3. Provider-level P&L reporting. Daily / weekly / monthly views of each provider’s billing volume, rejection rate, average days-to-payment, and net realised revenue after split (for clinics where space and overhead are split with the practitioners). The clinic owner sees the room economics; each provider sees their own numbers.
4. Claim pre-submission validation. Before a claim leaves the EMR, run it through a lightweight validator that checks the most common rejection patterns: invalid health card formats, missing referral numbers (ARF), age-restricted codes (A2A), incompatible code pairs (AD9), enrolment-type mismatches (EQP). Catches a meaningful percentage of rejections at the point of entry instead of three weeks later.
5. Third-party medical / report-fee workflows. Insurance forms, return-to-work assessments, MTO reports, immigration medicals, sports physicals, etc. Each has a different fee, a different turnaround SLA, and often a different payer (insurer vs patient vs employer). We build the intake, the fee calculation, the document handoff, and the invoicing.
6. Custom integrations between EMR and accounting. Clinics running QuickBooks Online, Xero, or Dext for accounting often re-key revenue manually because the EMR doesn’t push clean GL entries. We build the connector (typically as a nightly batch) with a clear mapping between OHIP/uninsured/block-fee revenue lines and the chart of accounts.
What we don’t build
A few things clinics ask us about that we’ll talk them out of:
- A whole new EMR. Building or replacing the EMR is a huge undertaking with a long compliance shadow (PHIPA, Ontario Health certifications, EMR Specification compliance). We are not the right shop for that and most clinics aren’t the right buyer.
- Anything that touches billing without PHIPA-aware architecture. Patient names, health card numbers, and visit-level data are PHI. The pattern that fails is bolting a generic CRM or accounting tool onto the EMR without thinking through what data goes where. We’ve written about PHIPA-compliant architectures for clinic AI deployments; the same principles apply to billing.
- Replacing your billing agent. If you outsource OHIP claim submission to a billing service (DoctorCare, OHIP Billing, MedPros, etc.), we don’t replace them. We build the dashboards and workflows that let you supervise them.
What it costs
Custom billing-adjacent work for an Ontario clinic typically falls in the $15,000-$50,000 range for a defined-scope project, depending on which of the six pieces above you need and how complex your EMR integration is. A patient portal alone (item #2) tends to land around $10,000-$20,000. A full rejection dashboard + provider P&L + accounting integration is usually $30,000-$60,000. Ongoing maintenance after launch is a small monthly retainer.
These are honest brackets for our shop. You’ll see lower numbers from offshore vendors and higher numbers from larger Toronto agencies. Both are real markets.
Where we fit
We’re a small Toronto studio that ships custom software, including for healthcare practices. We work with your existing EMR vendor, your existing billing agent if you have one, and your privacy officer. We don’t replace any of them.
If your clinic is leaving rejected-claim revenue on the table, your providers can’t see their own numbers, or your front desk is chasing $50 sick-note payments by hand, send us the specifics. The first call is free; you’ll leave with an honest read on whether custom development is worth the spend or whether you should fix it inside your EMR first.