The Ontario Health Card Version Code

The version code is the two letters printed after the 10-digit number on an Ontario health card. It is the smallest field on the card and one of the largest single causes of rejected OHIP claims.

The reason is structural: the health number essentially never changes over a patient's lifetime, but the version code changes every time the card is reissued. So a health number you captured correctly in 2023 is still correct today — and the version code attached to it may not be. Nothing in your chart flags the difference. The claim just comes back.

This is the full picture: what the code is, where it appears, why it changes, what it does on a claim, and the specific error codes it produces.

Anatomy of an Ontario health card

The current green photo health card carries eight pieces of information, per the ministry's own technical specification:

| # | Element | Notes | |---|---|---| | 1 | Health number | 10 digits | | 2 | Name | | | 3 | OHIP number | | | 4 | Expiry date of coverage | Month/year — not on all cards | | 5 | Version code | 1 or 2 alpha characters | | 6 | Health 65 indicator | Signifies eligibility for the Ontario Drug Benefit | | 7 | Date of birth | Labelled BORN / NÉ(E) | | 8 | Sex | |

Cards must be signed. Photo cards carry a digitized signature on the front; the older red-and-white cards were signed on the back.

A practical note that costs people claims: the green card shows three dates — BORN, ISS (issued), and EXP (expiry). Only the one labelled BORN/NÉ(E) is the date of birth. Reading the issue date as the birth date is a surprisingly frequent transcription error, and it produces its own rejection (VH8 — Date of birth does not match the Health Number submitted).

The 10-digit number is self-checking

The health number is not an arbitrary sequence. It satisfies a MOD 10 check digit routine — the tenth digit is a checksum computed from the first nine. The ministry recommends validating it locally precisely because doing so eliminates a whole class of rejections before submission.

The practical consequence: a transposed pair of digits in a health number will almost always fail the check digit test. Any billing system worth using should catch that at data entry. There is no equivalent check on the version code — two letters, no checksum, no way to tell locally whether they're current.

Where the version code sits on the magnetic stripe

On the photo card's Track I magnetic stripe, the version code is field 13, two characters, described in the specification as "XX (may be blank)." The issuer identification is 610054; the stripe also carries the health number, name, expiry, sex, and date of birth.

"May be blank" is the important part, and it's the direct answer to the red-and-white card question below.

What the version code means

The version code identifies which issuance of the card you're looking at. The health number identifies the person; the version code identifies the piece of plastic.

Every time a card is replaced, the ministry increments the version code. That happens when a card is:

• Renewed at the end of its validity period
• Replaced after being lost, stolen, or damaged
• Reissued following a name change or other update to the cardholder's record

The health number stays the same across all of those events. Only the version code moves.

That is the whole failure mode. A patient renews their card in March. Your chart still holds the version code from their 2019 card. The health number matches, the name matches, the date of birth matches — and the claim rejects, because the version code no longer corresponds to the card the ministry has on file.

Red-and-white cards and blank version codes

The older red-and-white Ontario health cards were issued without a version code. That's why the field is defined as "may be blank" on the stripe and formatted as "A or S" (alpha or space) in the claim record layout — the specification has to accommodate cards that never had one.

The ministry's rule for the claim field is precise:

Version of health card (can be 1 or 2 alpha characters). A one character version code may be left or right justified. Required for HCP claims. Must be present if version code appears on health card. Not required for RMB claims and blank for non-patient encounter claims.

Three things fall out of that:

1. For standard HCP (Health Claims Payment) claims, the version code is mandatory.
2. One-character version codes exist and are legal. If a card shows a single letter, submit the single letter — don't pad it with a guess.
3. For RMB (Reciprocal Medical Billing — out-of-province patients) the field is not required, because other provinces don't use Ontario version codes.

What "audit ID" actually refers to

This one gets searched a lot and is worth clearing up: there is no "audit ID" printed on an Ontario health card.

The term comes from the ministry's electronic services, not the card. When your billing software calls the Health Card Validation service or the MCEDT claim submission service, each message carries an audit ID — a version 4 UUID generated by the service to identify that individual transaction in the ministry's audit log. It looks like this:

3F2504E0-4F89-41D3-9A0C-0305E82C3301

32 hexadecimal digits in five hyphen-separated groups. It identifies a request, not a patient and not a card. If you're troubleshooting a failed validation with the ministry, the audit ID is the reference they'll ask for. It has nothing to do with anything you can read off the card in front of you.

Validating a card against the ministry

The version code is one of only two fields you can't verify locally (the other being whether the patient's coverage is currently active). Both are answered by the ministry's Health Card Validation (HCV) service — a real-time query that takes a health number and version code and returns an eligibility answer plus the cardholder's demographics.

Response codes are two characters, and the ranges themselves carry meaning:

| Range | Meaning | |---|---| | 00–49 | Card is invalid and the cardholder is not eligible | | 50–59 | Valid card, cardholder is eligible | | 60–89 | Card is invalid but the cardholder is eligible |

That middle-vs-upper distinction matters more than it looks. A 60–89 response means the person is covered — you will get paid for the service — but the specific card presented can't be used as-is.

The response codes you'll actually see

| Code | Response ID | Meaning | What to do | |---|---|---|---| | 05 | NOT_10_DIGITS | Submitted health number is not 10 numeric digits | Fix the format — this is a data entry problem | | 10 | FAILED_MOD10 | Health number does not exist on the ministry's system | Re-read the card; check for transposition | | 15 | IS_IN_DISTRIBUTED_STATUS | Pre-assigned newborn health number | Card not activated yet — wait, or bill once active | | 20 | IS_NOT_ELIGIBLE | Eligibility does not exist for this health number | Patient must contact the ministry | | 50 | NOT_ON_ACTIVE_ROSTER | Card passed validation | Bill normally | | 51 | IS_ON_ACTIVE_ROSTER | Card passed validation | Bill normally | | 52 | HAS_NOTICE | Card passed validation | Bill normally | | 53 | IS_RQ_HAS_EXPIRED | Card passed validation; card is expired | Still valid for billing; tell the patient to renew | | 54 | IS_RQ_FUTURE_ISSUE | Card passed validation; card is future dated | Bill normally | | 55 | RETURNED_MAIL | Card passed validation; cardholder must update their address | Bill normally; flag for the patient | | 65 | INVALID_VERSION_CODE | Invalid version code | The version code you hold is wrong — re-read the card | | 70 | IS_STOLEN | Card reported stolen | Patient needs a replacement card | | 75 | IS_CANCELLED_OR_VOIDED | Card cancelled or voided | Patient needs a replacement card | | 80 | DAMAGED_STATE | Card reported damaged | Patient should obtain a replacement | | 83 | LOST_STATE | Card reported lost | Patient needs a replacement card | | 90 | INFO_NOT_AVAIL | Information is not available | System issue — retry later | | 91 | ATTEMPTS_EXCEEDED | Validation attempts exceeded | You've hit the daily limit for this card |

Code 65 is the version code code. It sits in the 60–89 band, which tells you the whole story: the patient is eligible, you will get paid, but the version code on your record does not match the ministry's. Ask to see the card.

Code 53 catches people out in the opposite direction. An expired card still passes validation — expiry is not the same as ineligibility. Don't turn a patient away or convert them to private billing because the EXP date has passed.

The five-per-card-per-day limit

The ministry rate-limits validation: 5 validations per health card per day. Exceed it and you get code 91 — ATTEMPTS_EXCEEDED, which is not an answer about the card at all, just a "come back tomorrow."

Practically, this means brute-forcing a version code by trying combinations is not a strategy. You get five attempts, and a busy clinic re-validating the same card at check-in, at the claim, and again at submission can burn through them without anyone trying.

Two design responses follow, and any billing system handling volume should implement both:

• Cache results. A card's validity is a property of the card, not of the physician who checked it. A result that came back valid an hour ago is still valid.
• Batch. The ministry's SOAP interface accepts up to 100 health numbers per envelope, which is roughly 20× faster per card than sequential single calls. If you're validating a day's schedule, do it in one request, not fifty.

What a stale version code does to a claim

Now the part that costs money. These are the version-code-related codes from the ministry's error and Remittance Advice explanatory code lists, verbatim:

Rejection error codes

| Code | Reason for rejection | |---|---| | EH2 | Mismatched Version Code | | VH4 | Invalid Version Code | | VH1 | Health Number is missing/invalid | | VH8 | Date of birth does not match the Health Number submitted | | VH9 | Health Number is not registered with ministry |

EH2 is the classic stale-version-code rejection: the health number is real, the patient is real, and the two letters are from the previous card. VH4 is a format failure — something that isn't 1–2 alpha characters made it into the field.

Claims that reject with these codes appear on your Claims Error Report. They are deleted from the ministry's system and must be corrected and resubmitted to be considered for payment. Nothing happens automatically.

Remittance Advice explanatory codes

Some version code problems don't reject outright — they come back as adjustments or notices on your RA:

| Code | Description | |---|---| | E2 | Incorrect version code for service date | | E3 | Version code not on file for health number | | EF | Incorrect version code — services provided on or after the 20th of this month will not be paid unless the current version code is provided | | EV | Check health card for current version code | | EA | Service date is not within an eligible period — services on or after the 20th of this month will not be paid unless eligibility status changes |

EF and EA carry a deadline. They are the ministry telling you, in advance, that services rendered from the 20th of the current month onward will not be paid unless the record is corrected. That's an actionable warning with a clock on it, and it's easy to miss if nobody reads the RA line by line. Our guide to reading your Remittance Advice covers where these appear in the file.

The E-prefix pattern

There's a useful shortcut buried in the ministry's own taxonomy. Rejection error codes are prefixed by category:

• V — missing or invalid data relative to the field specification (format problems)
• E — ineligible patient or health care provider data (eligibility problems)
• A — missing or invalid data relative to the Schedule of Benefits (billing rule problems)

So VH4 is a format problem you caused, and EH2 is an eligibility problem the patient's card caused. Different fixes: VH4 you correct at your desk, EH2 requires seeing the card again.

How to stop version code rejections

1. Capture the version code at every visit, not once. The version code is the one identifier that changes. Treat it as a per-visit field, the way you'd treat a blood pressure, not a per-patient field like a date of birth.

2. Validate against HCV before the claim, not after. A code 65 caught at check-in costs thirty seconds. The same problem caught on a Remittance Advice costs a correction, a resubmission, and six weeks of float.

3. Never guess. There is no checksum on the version code and only five validation attempts per card per day. Guessing burns the budget and produces code 91, which tells you nothing.

4. Treat code 53 as billable. Expired card, valid coverage. Bill the claim; remind the patient to renew.

5. Read the E-series lines on your RA. EF and EV are the ministry warning you before it stops paying. They are the cheapest signal you will ever get.

6. Photograph the card rather than transcribing it. Most version code errors are transcription errors — a handwritten AB that was actually AR, or a version code read off a two-year-old sticker. Capturing the card image directly removes the step where the error is introduced.

The takeaway

The version code is two letters with no checksum, no local way to verify it, a hard five-checks-per-day ceiling, and a habit of changing without anyone telling you. That combination is why it punches so far above its weight in rejection statistics.

The fix isn't more diligence — it's removing the manual step. Validate the card against the ministry before the claim is built, cache the answer, and let the software flag a mismatch while the patient is still in the room.

---

SnapBill validates health cards against the Ministry of Health before claims are submitted — single or batched, with results cached so you don't burn the daily limit. Capture a card with your phone and the number, version code, and date of birth are read straight off it. Sign up free — no credit card.