OHIP · Ontario
An MCEDT batch built from the day's charts, checked before it leaves.
Ontario billing is a fixed-width file, a signed upload and a remittance advice that arrives later. The Clinic builds the file, refuses the claims the ministry would reject anyway, and imports the RA back onto the right lines.
- MCEDT claim batches
- MOD-10 health-number check
- EBS upload and submit
- Remittance advice import
What OHIP billing looks like
A file, a signed upload, and a remittance advice later.
OHIP does not adjudicate a claim while your patient is still in the room. Ontario clinics build a claims batch — a fixed-width file of claim header and service item records, per the ministry's Health Claims specification — and send it through MCEDT. Later a Remittance Advice comes back with what was paid, what was adjusted and what was refused.
That shape decides how the software has to behave. Because the remittance identifies each service only by its position within the claim, a line silently dropped on the way out puts every later payment onto the wrong service on the way back. The Clinic therefore refuses to build a batch containing an uncoded or non-sequential line rather than quietly renumbering around it.
The rail is resolved from the clinic's jurisdiction, and the batch is assembled from claims already routed through the carrier directory — carrier to funding source to rail — so an OHIP claim and a claim bound for a different payer never end up in the same file.
Claim file
The batch the ministry expects, down to the column.
Batch header, claim headers and service item records are laid out to the ministry's fixed-width Health Claims specification, with your provider registration number, specialty code and group number in the header and an eight-character accounting number carried on each claim so the remittance can be matched back to it. Fee amounts are computed in exact cents rather than floating-point dollars, because a claim file that is out by a cent is a claim file that is out.
- Fixed-width claim header and service item records per the ministry specification
- Provider registration number, specialty and group number in the batch header
- Accounting number echoed by the remittance advice, which is what makes matching possible
- Amounts computed in exact cents, never in floating-point dollars
Pre-flight
The claims the ministry would reject never get built.
A health number is validated against the ministry's MOD-10 check before anything is assembled, and a claim that fails it is refused with that reason rather than filed and bounced. Payment program and payee combinations are checked against the valid set. And because remittance items are matched by position, every line must carry a service code and the lines must be numbered from one with no gaps — a claim that breaks either rule comes back with the specific line named and a plain instruction for fixing it.
- MOD-10 health-number validation before the batch is built
- Payment program and payee combinations checked against the valid set
- Every line needs a service code — OHIP claims are all-or-nothing here
- Rejections name the line and say what to do, not just that something failed
Remittance advice
The RA imported once, onto the right lines.
A scheduled poll lists, downloads and imports whatever the ministry has published for each enrolled clinic, inside that clinic's own tenant context. The raw RA file goes to object storage and only its key is kept on the ledger row. Import is deduplicated on the ministry's resource identifier, so a monthly RA polled thirty times is imported exactly once — a claim settled twice is worse than a claim settled late.
- Scheduled list, download, parse and import per enrolled clinic
- Payment header with claim and item records parsed positionally, as the ministry emits them
- Deduplicated on the ministry resource id — an RA cannot import twice
- The raw file is stored as an object; the ledger keeps only its reference
OHIP coverage in the gateway
- MCEDT
- submission channel
- 5
- readiness checks
- Daily
- remittance poll
- 0
- double-imported remittances
Before your first submission
What an Ontario clinic has to configure.
OHIP submission cannot be switched on from software alone, by design — the ministry issues part of the credential set only after conformance testing. The readiness report names all five gaps rather than letting one of them hide.
- 01
Jurisdiction
Set the clinic's jurisdiction to Ontario, Canada in Regional Settings. That is what routes its claims to the OHIP rail.
- 02
Provider registration
Your six-digit ministry provider registration number, the two-digit specialty code, and your group number — four zeros for a solo practice. All three go in the batch header.
- 03
GO Secure credentials
The GO Secure username and password your practice signs in with, plus the service user identifier for the EBS account. Together they authenticate the upload.
- 04
Software conformance key
Issued by the ministry only after mandatory conformance testing. Until it is entered, the platform builds and validates the batch file and reports plainly that nothing was transmitted.
- 05
Signing certificate
EBS submissions are WS-Security signed. The certificate and private key are stored encrypted against the rail configuration, and the gateway refuses to send unsigned.
- 06
Ministry endpoint
The conformance endpoint is handed over during onboarding. Sandbox and production are separate configurations with separate credentials, so neither can be used by accident.
The honest edges
What the OHIP rail does not do yet.
Ontario has more than one billing rail, and OHIP covers only the insured-services half of it. Here is what this gateway does not cover.
No health card validation
Health Card Validation against the ministry is not implemented. The MOD-10 check catches a mistyped number; it does not tell you whether the card is currently eligible.
No claim status inquiry
There is no status poll. What happened to a submitted batch is answered by the remittance advice and by the ministry's own reports.
Extended health is a different rail
Private and extended-health claims in Ontario go through TELUS eClaims, which is scaffolded in the platform but deliberately not switched on: it fails closed until the certified vendor agreement and integration kit are in place, rather than quietly filing nothing.
Conformance testing is not optional
The ministry's conformance process gates production access. The platform is built to pass it and the readiness report tells you exactly which pieces are still missing, but no software can shorten the process.
OHIP questions
What Ontario clinics ask before they switch.
Does The Clinic do OHIP billing?
It builds MCEDT claim batches from the clinic record and, once the full ministry credential set is configured, uploads and submits them over EBS. Until then the batch file is still built and validated so you can see precisely what would be sent — and the record says it was not transmitted rather than implying that it was.
What is MCEDT?
Medical Claims Electronic Data Transfer — the ministry's channel for sending Ontario claims files and retrieving reports and remittance advice. Access runs through the Electronic Business Services gateway using GO Secure credentials and a signed request.
Why would a claim be rejected before it is even sent?
Because the ministry would reject it too, and finding out here is cheaper. A health number that fails the MOD-10 check, an invalid payment program and payee pairing, a service line with no code, or lines that are not numbered from one with no gaps all stop the build with the specific problem named.
Why does every line need a service code?
The remittance advice identifies each service by its position in the claim, not by an identifier the software chose. Drop a line on the way out and every payment after it lands on the wrong service on the way back — so OHIP claims are all-or-nothing here rather than partially filed.
How is the remittance advice imported?
A scheduled job lists what the ministry has published for each enrolled clinic, downloads it, parses the payment header with its claim and item records, and imports the result against the original claims. Import is deduplicated on the ministry's own resource identifier, so the same RA can never settle a claim twice.
Can we start before conformance testing is finished?
Yes, and most clinics do. Configure what you have, run the readiness report, and use the built batch files to verify your data is complete. The five readiness checks go green as the ministry issues each piece; the last of them cannot be satisfied by software.
Related
The rest of the interoperability surface.
- Standards and exchanges
FHIR R4, NABIDH over HL7 v2.5, and DICOMweb imaging in one place.
- NPHIES (Saudi Arabia)
Eligibility, pre-authorisation, claims and remittance on FHIR R4.
- eClaimLink (Dubai DHPO)
How a Dubai facility files a Claim.Submission through the DHPO.
Ready to try The Clinic
See it run your clinic in 30 minutes.
Book a personalized demo. We'll use your clinic's real workflows — not a generic walkthrough.
No credit card. No slides. 30 minutes.