Built around patient data.
Handling OHIP claims means handling protected health information. We built OHIPay around that from the start. Here is how patient data is stored, moved, and shown, in plain terms and without overstating what the product does.
What we do to protect it
These are current engineering practices in the product, not certifications. They describe how the system is actually built. Nothing here claims compliance under a specific framework.
Encrypted at rest and in transit
Health card numbers and demographic details are encrypted at rest and in transit. They're decrypted only when a claim or a lookup actually needs them.
PHI stays server-side
Patient identifiers are decrypted in-process on the server, for the one moment a task needs them. They never reach the browser or a client-side cache. Lists mask names and health numbers, and show them in full only where the work requires it.
Card images never touch disk
Scan a health card and the image is read in memory, then dropped. The photo is never written to disk.
What's scoped to you, and what's shared
Claims, rosters, submission batches, and reports are scoped to you, enforced on the server rather than hidden in the interface. Patient records are the one exception: a patient record is shared by the physicians who have that patient's health card in hand, so a patient two doctors both see is one record, not two. That's a deliberate design choice, and we'd rather state it here than have you discover it later.
Sensitive access is logged
Reads and edits to patient records land in an audit trail. Who opened what, and when, stays answerable after the fact.
Canadian data residency
The service and its data are hosted in Canada. If you need specifics on where your data lives and how it's stored, we'll walk through them before you commit.
Want the detail behind any of these? Ask how your data would be handled before you commit. We'd rather answer a specific question than point at a logo.
Where your data lives, and who else touches it
Here are the details we'd otherwise walk you through in a call. Everything below is how the system runs today, not a roadmap.
The live system: Québec
The application and its database run on servers at OVH in Beauharnois, Québec. Patient identifiers and demographic fields are encrypted at rest, and everything in transit runs over TLS.
The backups: Montréal, and we hold the only key
A full database dump runs every six hours. It's encrypted on our own server before
it goes anywhere, then stored in Amazon S3 in the Canada (Montréal) region,
ca-central-1. The key that decrypts it is kept off that server, so
Amazon holds ciphertext it cannot read. Live data and backups both stay in Canada.
Notice before any of this changes
We give 30 days' written notice before adding a company to the list below or moving where data is stored. If you object and we can't work it out, you can leave without waiting out the notice.
| Company | What they do for us | Patient data? | Where |
|---|---|---|---|
| OVH | Runs the servers the application and database live on. | Yes — all of it | Beauharnois, Québec |
| Amazon Web Services (S3) | Stores the encrypted database backups. | Encrypted only; they can't read it | Canada (Montréal), ca-central-1 |
| Resend | Sends account email — invitations, password resets — and our own operational alerts. Alerts can name a physician and practice-level dollar totals. Never patient data. | No patient data | United States |
| Google (Fonts) | The health-card lookup pages load one web font from Google. The request carries page metadata — IP address, browser, page URL — and no patient content. | No — page metadata only | United States |
| Medinote | A separate telehealth platform. If you turn on the Medinote connection, patient data flows from Medinote into OHIPay. | Yes — flows in from Medinote | Per Medinote's own terms |
| Amazon Bedrock | AI suggestions. Built but switched off — no AI provider receives any data today. Turning it on would trigger the 30-day notice above. | None today | Canada, ca-central-1 |
The Ministry of Health isn't on this list. MC EDT and health-card validation are how your claims reach the payer — the Ministry is who you're billing, not a company we hand your data to.
What we don't claim
Saying what OHIPay is not matters just as much. So here it is, without spin.
- We don't claim SOC 2, HIPAA, ISO, or any other compliance certification.
- We don't claim endorsement or certification by the Ministry of Health or OHIP.
- The billing engine is advisory: it flags likely issues, and never guarantees a claim will be accepted or paid.
Independent software
OHIPay is independent billing software and is not affiliated with, endorsed by, or certified by the Ontario Ministry of Health or OHIP.
It helps you prepare and submit claims, and warns about likely rejections. The decision to accept, adjust, or reject a claim rests entirely with the Ministry.
Ask us anything before you rely on it
If your practice has specific requirements about how patient data is stored and handled, bring them to a walkthrough and we'll go through the details.
Prefer email? Write to hello@ohipay.ca