OHIP error report
V31
Claim validation
OHIP error code V31: error in claim header on an ohip claim
V31 means the claim header is missing one of three required fields: the group number, the health care provider number, or the specialty code. The individual service lines may be perfectly correct and still reject.
Ministry wording: Error in claim header. Most often affects All specialist practices.
You already know V31. A single rejection is rarely the whole pile. Specialists we work with recover $10,000 to $100,000+ from rejected and unpaid claims, then average a 20–40% revenue increase within 90 days.
Each minute looking this up is about $5 of clinic time.
V31 at a glance
V31 is a V-series validation edit, so the claim is rejected on the Claims Error Report and never reaches adjudication. The ministry condition names exactly what it tests: an error in the claim header, missing any of the following, group number, health care provider number, specialty code.
The distinguishing feature of V31 is that it is not about the service. A claim header describes who is submitting and under what registration. Every diagnosis, fee schedule code, modifier and date on the claim can be right, and V31 will still reject it, because the ministry cannot establish who the claim belongs to.
That is why V31 tends to arrive in volume rather than singly. A header is built once per claim or per batch from stored configuration, so when a field is absent it is absent for everything that was submitted the same way. A practice seeing one V31 should expect to find a block of them.
Why it fires
- The group number is missing from the claim header.
- The health care provider number is missing from the claim header.
- The specialty code is missing from the claim header.
- A software change, new provider setup or new group affiliation left one of the three unpopulated in the submission file.
New provider setup is the most common cause. A locum, a new associate or a returning physician is added to the billing system, the service-level details are completed because they are visible on every claim, and one header field is left blank because nothing on the screen draws attention to it.
Group affiliation changes produce the same result. Where a physician moves between groups, or a group number changes, the header may keep a value that no longer applies or lose it entirely. The claim then describes a submitter the ministry cannot match.
Software and interface changes are worth checking explicitly, because the header is assembled rather than typed. A field can be present in the provider record and absent from the outbound file, which means re-entering it in the interface changes nothing. If the data is demonstrably stored and V31 persists, the submission file is where to look.
The ministry maintains separate codes for the related registration failures, which helps narrow the cause. EQ1 is a practitioner not registered with OHIP. EQ2 is a specialty code that is inactive or not registered on the service date. V08 is an invalid specialty code. V31 is none of those. It means a required header field was not supplied at all.
What it costs
The whole claim is rejected, not one line of it. Every service on a claim with a defective header is unpaid until a corrected claim is accepted.
This is the reason V31 is more expensive than its simplicity suggests. Service-level edits reject one item. A header edit rejects everything the header covers, so a single missing field can take out a full submission.
Because headers come from stored configuration, the exposure continues until someone reads the error report. Nothing in the clinical or billing workflow changes to signal the problem, and the claims keep being built the same way.
Services rendered on or after 1 April 2023 carry a three-month submission window from the date of service, per ministry INFOBulletin 230402. A header misconfiguration that nobody reads for a quarter can put every claim submitted in that quarter against the window at once.
Step-by-step: how to clear this rejection
- Read the Claims Error Report line and confirm the code is V31 rather than EQ1, EQ2 or V08, which are registration and specialty failures rather than missing fields.
- Identify which of the three header fields is absent: group number, health care provider number, or specialty code.
- Correct the value in the provider or group configuration rather than on the individual claim.
- Confirm the corrected value reaches the outbound claim file and not only the entry screen.
- Resubmit the affected claims inside the three-month window, working from the oldest date of service forward.
Fix the configuration first and the claims second. A header is generated, so editing one claim clears one rejection and leaves every future claim on the same path.
Establish the scope before resubmitting. Because the cause is configuration, the affected set is usually defined by a provider, a group or a date range rather than by individual claims, and knowing which tells you how many claims need working and how close the oldest is to the window.
If the field is visibly stored and V31 keeps firing, stop re-entering it. Some systems maintain a separate submission record from the display record, and in that case the data entry was never the problem.
How to fix it going forward
- Validate all three header fields as part of adding or changing any provider, group or affiliation.
- Check the outbound claim file after any billing software change, upgrade or interface change.
- Submit a small test batch for a new provider before submitting their full volume.
- Read the error report weekly, because header failures arrive in blocks rather than one at a time.
Treating provider setup as a billing task rather than an administrative one is the control that matters. The header fields are invisible during normal work and are only ever wrong because of a change, so the change is the moment to check them.
A test batch is the cheapest insurance available here. Ten claims submitted and checked for a new provider costs an afternoon of delay. Four hundred claims rejected on a header field costs a submission cycle.
Weekly review is what converts a configuration error from a quarter of lost billing into a few days of it. These codes do not trickle, so the review interval is close to the entire exposure.
Is it recoverable?
Recoverable by resubmission inside the window
Correct the missing header field in the provider or group configuration, then resubmit the affected claims inside the three-month window from each date of service.
V31 is fully recoverable while the claims are inside the window. Nothing clinical is in question and no documentation is required beyond the configuration itself.
Sequence the backlog by date of service. Each claim carries its own three-month window, so a block of header rejections expires continuously from the oldest forward rather than all at once.
After the window closes, INFOBulletin 230402 allows claims that reached the Claims Error Report inside three months to be corrected and resubmitted through the ministry stale-date process, with the report line serving as evidence of timely submission. A claim never submitted inside the window runs through a written application instead, which is a separate process this page does not describe.
For in-province services on or after 1 April 2023, claims must be submitted within three months of the date of service, not six. Ontario INFOBulletin 230402 is the Ministry notice. Many third-party pages still quote six months. That window is closed for current work. If the original claim reached the Claims Error Report inside three months, a corrected resubmission can still be filed after the window in the Ministry's stale-date process. If the claim was never submitted in time, payment may be recoverable by written application. That is not a routine resubmit.
Related codes
Frequently asked questions
- What does OHIP error code V31 mean?
- V31 means the claim header is missing the group number, the health care provider number, or the specialty code. The ministry condition names those three fields.
- Why did the whole claim reject when only the header was wrong?
- Because the header identifies who is submitting and under what registration. Without it the ministry cannot attribute any service on the claim, so every line rejects rather than one.
- How is V31 different from EQ1 or EQ2?
- EQ1 means the practitioner is not registered with OHIP and EQ2 means the specialty code is inactive or not registered on the service date. V31 means a required header field was not supplied at all, which is a submission problem rather than a registration one.
- The field is filled in on our system. Why does V31 keep firing?
- Some systems keep a separate submission record from the screen record, so a header field can be stored and still absent from the file reaching the ministry. Check the outbound claim file rather than re-entering the value.
Related reading
References
For how error reports relate to the remittance advice, see how to read your OHIP remittance advice and what rejection codes actually mean. Official wording for this code: Ministry of Health, Error Report Rejection Conditions (December 2022).