Disclosure: DROZlegal publishes this guide and builds the records-request tracker described below. Third-party statistics and quotes here are sourced from Ontario personal injury lawyer Roger Foisy's published commentary on medical-records fees, which reports the Ontario Medical Association's recommended figures, and from Canadian Lawyer's coverage of Ontario's July 2026 accident-benefits reform — verified for this article, not ours.
The record chase that stalls an Ontario PI file
A personal injury claim doesn't move until the records show up. Hospital charts, clinic notes, family-doctor files, imaging reports — every one of them has to be requested, paid for, chased, and logged before a demand package can go out. None of that work is legally complicated. All of it is slow, manual, and easy to lose track of across a busy PI file list.
The cost side compounds the problem. There's no statutory cap on what an Ontario hospital or clinic can charge to release a patient's own file. The Ontario Medical Association's guideline recommends $30 for the first 20 pages and 25 cents per page after that — but that's a recommendation, not a rule — one Ontario personal injury firm calls it "rarely followed" — and actual invoices "range widely, often amounting to hundreds of dollars." Source: Foisy & Associates (injurylawyercanada.com), "Payment for Medical Records in Ontario," 2014. The fee figures are as reported there; confirm the OMA's current schedule before relying on them.
Roger Foisy, the Ontario PI lawyer whose firm published that piece, doesn't soften the effect: "these exorbitant costs impact my clients' net settlement values and increase costs for insurance companies." Every dollar a firm pays out to a records custodian is a disbursement the client's recovery eventually absorbs — which makes tracking those requests a billing problem as much as a workflow one.
What DROZlegal's records-request tracker does today — and what it doesn't
This is the one piece of DROZlegal's personal injury capability that's genuinely live in production today, and it's worth being exact about its shape rather than rounding it up. api/v1/pi.py exposes eight routes; six of them are the records-request tracker (services/records_request_service.py, models/records_request.py), and the frontend surface is a single page — frontend/src/pages/pi/index.tsx at /pi — which is, today, the entire PI user interface. Source: docs/CAPABILITIES.md, Section 7.
What the tracker actually does is deliberately narrow:
| What it tracks | Why it matters on a PI file |
|---|---|
| Custodian/records taxonomy | Each request names who holds the document, typed against a fixed custodian list — hospital, clinic, family physician, specialist, OHIP, police, employer, insurer, CPP, other — alongside a free-text field for what was actually asked for ("CNRs 2019–present," "MVCR," "T4s + NOAs") |
| Chase status, with dates | Six statuses — draft, sent, follow-up, partial, received, abandoned — plus requested, follow-up-due and received dates, so a request never sits logged as "sent" with nobody chasing the reply |
| What the custodian charged | The fee is stored on the request itself, so a file's records spend is captured as it happens rather than reconstructed at settlement — with the caveat immediately below about what that does not yet do |
One caveat worth stating precisely, not glossing over: a medical_records disbursement category shipped alongside the tracker (migration 082), and it is easy to read more into that than it deserves. It is a permitted category value on DROZlegal's firm-wide disbursements table — not a field on the records-request record — and that firm-wide Disbursements feature is switched off in production (ENABLE_DISBURSEMENTS, absent from the production configuration): its API returns an error and disbursements are excluded from the billing run entirely.
So the honest version is narrower than "disbursement tracking." The tracker records what a custodian charged; it does not put a disbursement line on a client invoice today. What migration 082 did was make the ledger ready to classify PI records charges under their own By-Law 9 heading instead of burying them in "other" — useful groundwork, not a live billing path. Treat the records spend the tracker captures as a working record, and reconcile it into billing the way you do now. Source: docs/CAPABILITIES.md, Sections 7 and 11.
The SABS clock that's built but doesn't show up on a PI matter yet
Ontario's accident-benefits regime changed materially in the middle of this year, and it's the kind of shift a records-tracking tool needs to sit next to. As of July 1, 2026, Ontario Regulation 383/24 restructured the Statutory Accident Benefits Schedule: what used to be one standard no-fault package is now split into a small mandatory core — medical, rehabilitation, and attendant care benefits — and a longer list of coverages (income replacement, non-earner benefits, caregiver and housekeeping support, and more) that drivers must now actively elect and pay for separately. Source: Canadian Lawyer, "Statutory Accident Benefits Schedule: what's new after July 1, 2026," published 2026.
DROZlegal's deterministic deadline-rules engine already has SABS and LAT deadline math built in, including a dedicated branch for that July 1, 2026 reform date. That's real, shipped code. What it isn't yet is reachable from any PI screen. Today those rules compute only through the platform's generic deadlines endpoint, with a lawyer hand-supplying the rule authority — nothing on the /pi page surfaces a SABS clock automatically when a matter opens. Source: docs/CAPABILITIES.md, Section 7.
That's an honest architecture note, not a hidden feature: the calculation logic exists and ships; the last mile connecting it to a PI file's screen does not exist yet.
What happens when an injury matter hits intake
One PI capability beyond the tracker is genuinely live: intake triage. When a matter comes in through DROZlegal's public intake forms carrying injury-related language — "injury," "accident," "MVA," "slip and fall," "dog bite" — a keyword branch in the intake-triage logic catches it, classifies it under a dedicated personal_injury triage category, and seeds a four-item checklist automatically: identification, the accident or police report, insurer correspondence, and a medical-records authorization. A lawyer reviewing that intake sees the checklist waiting, not a blank matter. Source: docs/CAPABILITIES.md, Section 7; see also our guide to AI legal intake software for how triage works across every practice area, not just PI.
This sits upstream of the records tracker in the workflow: intake flags the file as an injury matter first; the records chase the tracker manages starts once someone begins requesting the medical file the checklist calls for.
What's not here yet
Three gaps are worth naming directly, because rounding any of them up would misrepresent what a firm gets today:
- The PI intake preset isn't a default. The four-item checklist above seeds from the matter type in code, but the dedicated "Personal Injury Intake" form that pairs with it — the one whose upload fields map onto those checklist items, so a client's upload satisfies them — is created by a manual seed script run by DROZlegal's team. A new organization does not get it on signup.
- Nothing auto-seeds a SABS deadline pack when a PI matter opens. As covered above, the deadline math exists but has to be invoked by hand through the generic deadlines endpoint; no PI screen triggers it on its own.
- Contingency-fee billing is not enabled in production. The code exists — two of the eight
pi.pyroutes are contingency-settlement routes, grounded in Solicitors Act s.28.1 and O. Reg. 563/20 — but the feature flag controlling it is off, the contingency endpoints return a not-found error, and the settlement-invoice page is unusable as a result. If a vendor conversation brings up contingency billing, ask directly whether it's live in production or shipped-but-off; for DROZlegal today, it's the latter.
None of this is a hedge on the records tracker itself — that piece works today, on a real page, for a real purpose. It's a hedge on calling personal injury a finished practice module, which DROZlegal's own internal capability documentation is explicit it is not; the practice areas that are further along are on the product overview. What exists here is a first PI capability: a records-request layer, an intake checklist, and a deadline library waiting for its screen — not a full PI practice module, and no firm has yet run a real personal injury matter through it. The same propose-then-approve discipline behind all of it — a checklist seeds itself, a tracker logs a request, but a lawyer still decides what happens next — is the pattern our Lawyer AI Academy guide walks through across every practice area on the platform, not just this one.
Update, September 16, 2026. This page covers what's built; it doesn't cover how to evaluate what to buy next. For the general vendor-evaluation criteria a PI practice should run any AI tool through — case-value prediction, medical-records review, disbursement tracking, insurer-communication handling, and data residency — including where DROZlegal itself doesn't yet have a dedicated answer, see our AI vendor checklist for an Ontario personal injury practice.