10.4 Verifying Report Accuracy & Avoiding Common Reporting Errors

Test plan task 5.G — "verify the accuracy of generated reports prior to distribution (e.g., check for errors)" — is the last task statement in the CEHRS blueprint, and it exists because a wrong report is worse than no report. A decision made on bad numbers is harder to undo than a decision deferred. Knowledge statement 5.K7 names the common reporting errors: missing fields and too much data on the report.

The Pre-Distribution Validation Checklist

1. Verify the parameters

Confirm the report ran with the parameters you intended before looking at a single number:

• Date range and date basis. Was the report run on date of service, date of posting, or date of entry? A financial report run on posting date will not match one run on service date, and neither is wrong — but they answer different questions.
• Population filters. Location, department, provider, payer, financial class, patient status.
• Inclusions and exclusions. Are cancelled encounters in or out? Deceased patients? Test patients from the training environment?
• As-of date. A report run today for last month looks different from the same report run at month-end, because activity posted in between.

2. Reconcile totals to a known source

Compare the report against something already trusted:

• Total charges on a financial report against the month-end close
• Patient counts against the census or the scheduling system
• Encounter counts against the billed-encounter count
• The same measure from the prior period, to see whether the change is plausible

3. Spot-check individual records

Open three to five records from the report and confirm they belong there. Then — and this is the step people skip — find a record that should be on the report and confirm it appears. Verifying only what is present catches over-inclusion but never catches omission.

4. Sanity-check the shape of the results

• Zero rows almost always means a filter or date-basis error, not that nothing happened.
• Impossible values — negative counts, rates above 100%, ages over 120, dates in the future.
• Denominators larger than the population or numerators larger than denominators.
• Sudden step changes that coincide with a software upgrade, a template change, or a new interface, which usually indicate a data capture change rather than a real clinical change.
• Duplicates — the same patient appearing twice, usually from a join that multiplied rows or from a duplicate MRN (Section 2.2).

5. Confirm the fields are complete

Missing fields is the first error NHA names. Check for columns that are blank for most rows, a heading with no data beneath it, truncated text, and required identifying columns that were left out — a patient list with no MRN cannot be acted on safely.

The Two Named Errors

"Too much data" is also a privacy failure, not just a usability one. A report that includes Social Security numbers and full addresses because they were available in the table violates the minimum necessary standard even if every recipient is authorized to see the report's subject matter.

Common Root Causes

Labeling and Distributing a Report

Every distributed report should state, on the report itself:

• Title and purpose
• Run date and time, and the as-of date of the data
• Parameters — date range, date basis, filters, and exclusions
• Data source — which system or warehouse
• Who produced it
• Confidentiality marking when it contains PHI

Distribution rules follow from Sections 6.5 and 9.2:

• Send only to recipients with a need to know, and include only the fields their purpose requires.
• Use a secure channel — internal secure network location or encrypted transport, never personal email or an unapproved cloud service.
• Aggregate where possible. If the recipient needs a rate, send the rate, not the patient list behind it.
• De-identify when the purpose does not require identifiers, using the Safe Harbor or Expert Determination methods in Section 9.1. Be alert to small-cell re-identification risk: a report showing "1 patient with this diagnosis at this clinic" can identify that person even without a name.
• Retain and destroy printed and electronic reports on the organization's schedule (Section 3.2). Reports left on a shared drive indefinitely become an unmanaged PHI repository, and printed reports abandoned in a conference room are a disclosure.

When You Find an Error After Distribution

Do not quietly reissue. Notify every recipient that the report was incorrect, state specifically what was wrong and which conclusions are affected, distribute the corrected version clearly labeled as a correction with a new run date, and — if the report was used for an external submission such as a registry or a payment program — follow that program's correction process. Then fix the cause, not just the output, so the next run is right.