Medical Data Validation: Rules That Catch Bad Fields

Medical data validation checks each extracted field against rules it must pass before it is accepted: the right format, a value inside a sensible range, and a code that exists on the current code list. A field that fails goes to a person. A field that passes is only plausible, so validation narrows review instead of replacing it.

What medical data validation checks before a field is accepted

Medical data validation checks whether a single extracted value could be correct for its field. It cannot prove the value matches the page. It can prove a value is impossible, such as a future date of service, an NPI with a bad check digit or a diagnosis code that does not exist. Those failures are cheap to catch.

Single-field rules fall into three groups. Format rules check the shape of a value: length, allowed characters and position of letters and digits. Range rules check that a value falls inside limits that make sense for the field, such as a date between the patient's birth and today. Code set rules check that a code appears on the official list in force on the date of service.

Each rule should state what happens on failure. Most teams route a failed field to the review queue with the rule's name attached, so the reviewer knows what to look for on the page. A few failures should hold the whole document, such as a missing member ID on a claim that cannot be posted without one.

Rules that compare two fields are a separate layer. A line total that does not match the claim total, or an admission date after a discharge date, needs both values at once. Those are covered in the guide on what cross field checks catch that single-field rules miss.

Validation rules for extracted fields: format, range and code set

Validation rules for extracted fields should match each field type to the rule that can actually fail it. Identifiers get format and check-digit rules. Dates get range rules. Amounts get format rules. Codes get code set rules. The table below gives one rule per common field with a passing and a failing example value.

All example values are fictional or are published examples from the source named in the row. The extraction date for the date rule is taken as October 16, 2026.

The sources for those rules are short and worth reading. The CMS requirements for the NPI check digit say an NPI is nine digits plus a check digit computed with the Luhn formula, calculated as if the 80840 prefix were present, and work the example 123456789 to a check digit of 3. The CMS page on Medicare Beneficiary Identifiers sets the MBI at 11 characters without those six letters, and the CMS MBI format document supplies the example 1EG4-TE5-MK73.

Range rules need care with the limits. A date-of-service rule should allow today but not tomorrow, and should not stop at an arbitrary past year, since corrected claims and appeals carry old dates. A birth-date rule should allow very old patients and newborns.

For lab reports, validate the shape of a result, never its medical meaning. A result field should hold a number or an allowed text value with a unit that matches the test. A result outside the printed reference range is still a valid value, and flagging it is the lab's job, not the extraction rule's. Lab report fields and their layout are covered in the lab reports category.

How should validation treat missing and blank fields?

Handling missing and blank fields starts by telling three cases apart: a miss, where the value is on the page but extraction did not find it; a true empty, where the page leaves the field blank on purpose; and a skipped page, where the value sat on a page that never reached extraction. Each needs a different response.

A true empty should pass. Many fields are required only in some cases. The Medicare Claims Processing Manual chapter on the UB-04 marks form locator 12, the admission or start of care date, as required for inpatient and home health bills, so a blank one on an outpatient bill is expected. A validation rule that demands the field on every UB-04 will route correct documents.

Some blanks are written as values. The same chapter tells providers to enter zeros for all eight digits of form locator 10 when the patient's full birth date is unknown. A date rule that rejects 00000000 as an impossible date will reject a valid entry.

A miss and a skipped page look the same in the output: an empty field. To tell them apart, compare the document's page count with the pages processed, and check whether the field's usual region exists on any processed page. When pages are missing, route the whole document, since every field on the lost page is missing too.

How blanks should count when you test extraction accuracy is a separate question, answered in the guide on how blank fields should count toward extraction accuracy.

Validating medical codes against ICD-10, CPT and CARC lists

Validating medical codes means checking that each code exists on the official list and was in force on the date of service. A pattern check only proves a code has the right shape. Code lists change on fixed schedules, so a validation rule must load the list version that matches the service date, not only the newest one.

ICD-10-CM diagnosis codes

The CMS ICD-10 codes page publishes the yearly code files and says the FY 2027 ICD-10-CM files apply to patient encounters and discharges from October 1, 2026 through September 30, 2027. A rule for a March 2026 date of service should use the prior year's list.

Pattern is not enough for ICD-10-CM. The FY 2027 ICD-10-CM Official Guidelines for Coding and Reporting say codes have 3, 4, 5, 6 or 7 characters and that a code is invalid if it has not been coded to the full number of characters required. So E11 passes a pattern check but fails a list check, because it is a category with subdivisions. The NLM Clinical Table Search Service API for ICD-10-CM returns E11.9 as a code and does not return E11 on its own.

CPT and HCPCS procedure codes

The CMS page on the Healthcare Common Procedure Coding System explains that HCPCS Level I is CPT, maintained and republished each year by the American Medical Association, and describes CPT codes as five numeric digits. HCPCS Level II codes, maintained by CMS, are a single letter followed by four digits. The CPT list is licensed from the AMA, so a CPT rule needs a licensed current copy. For Level II, the NLM Clinical Table Search Service API for HCPCS Level II returns G0008, the example in the table above.

Claim adjustment reason codes

The X12 Claim Adjustment Reason Codes list prints a start date for each code and, for retired codes, a stop date. Code 15, about a missing or invalid authorization number, shows a stop date of 05/01/2018. An EOB after that date carrying CARC 15 deserves a second look, since a misread code is likelier than a retired one.

Does a passed validation rule mean the medical data is right?

A passed validation rule means the medical data is possible, not that it is right. A misread can produce another valid value. A date of service read as 03/18/2026 instead of 03/13/2026 passes every date rule. A diagnosis code with one digit misread can land on another real code. Validation cannot see the page.

This is why validation and confidence-based review work together. Validation catches impossible values even when the software was confident. Review catches wrong but possible values when the software was unsure. Neither catches a confident misread that happens to be valid, which is why teams sample fields that skipped review.

That sample is the only way to measure the errors validation lets through. The guide to sampling accepted fields for quality checks covers how many to pull and how to stratify them.

Schema Care shows a reviewer each field that scored under your threshold highlighted on the original page, which is where a value that passed every rule but still looks wrong gets settled; the interactive threshold demo shows a fictional EOB working that way.

Medical data validation rules that reject good data

Medical data validation rules that are too strict reject valid values and fill the review queue with fields that were right. Each false rejection costs a reviewer's time and teaches reviewers to approve flagged fields without looking. A rule should fail only values that are impossible, never values that are merely unusual.

Common over-strict rules are easy to list:

• A procedure code rule that accepts only five digits rejects every HCPCS Level II code, since those start with a letter.
• An MBI rule that expects dashes rejects identifiers typed without them, though CMS says the dashes are not part of the MBI.
• A birth-date rule that rejects 00000000 rejects the UB-04's documented entry for an unknown birth date.
• A name rule that allows only letters rejects hyphens, apostrophes and spaces that are part of real names.
• An amount rule that rejects negatives rejects every credit or reversal that a statement or remittance prints with a minus sign.
• A member ID rule built from one payer's format rejects every other payer's IDs.
• A lab result rule that rejects values outside the reference range rejects real abnormal results.

Test every new rule on a set of known-good documents before it goes live. If a rule fails more than a handful of fields that reviewers then approve unchanged, loosen it or scope it to the document types and payers it fits. Track how often each rule's failures end in an unchanged approval. A rule whose failures are almost always approved is costing time without catching errors.