4.4 Identifying, Reporting & Reconciling Data Discrepancies
Key Takeaways
- Discrepancies arise within one EHR, between the EHR and the practice management system, and between the EHR and outside systems, and each type has a different resolution owner.
- Data validation techniques include field-level edits, cross-field logic, referential integrity checks, duplicate detection, and reconciliation reports.
- The specialist identifies and reports discrepancies but does not unilaterally alter clinical documentation or merge records.
- A demographic mismatch is corrected in the source system of record so the correction propagates rather than being patched in each downstream system.
- Every discrepancy resolution is documented with what was found, who was notified, what was changed, and when.
Two consecutive test plan tasks make discrepancy management a named CEHRS duty: task 1.K (identify data discrepancies within and among multiple EHRs, practice management systems, and other software systems) and task 1.L (report or reconcile those discrepancies). Knowledge statement 1.K23 adds data validation techniques and procedures. This is quality control work, and it is one of the places where scope of practice matters most.
Where Discrepancies Come From
| Type | Example | Usual Owner of the Fix |
|---|---|---|
| Within one EHR | Chief complaint says right knee; exam says left knee | Authoring clinician, via addendum |
| EHR vs. practice management | Insurance updated at the desk but not reflected on the claim | Registration/billing, in the source module |
| EHR vs. laboratory or imaging system | Order shows three tests; result returns two | Interface analyst plus ancillary department |
| EHR vs. outside EHR or HIE | External summary lists a medication the local list does not | Clinician, through reconciliation |
| EHR vs. registry | Immunization registry shows a dose the chart does not | Trained staff per policy |
| Interface failures | Messages queued or rejected; results silently missing | IT/interface team |
| Duplicate or overlaid records | Same patient under two MRNs | HIM department only |
Validation Techniques That Catch Them
Knowledge statement 1.K23 is about the mechanics of finding errors before a human notices them.
- Field-level edits constrain what can be entered: a date of birth cannot be in the future, a ZIP code must have five or nine digits, a policy number must match the payer's format mask.
- Cross-field logic compares fields to each other: a delivery procedure on a male patient, an age that conflicts with the date of birth, a discharge date earlier than the admission date.
- Referential integrity confirms that selected values still exist and are active — the provider is not terminated, the payer ID is current, the CPT code is valid for the date of service.
- Duplicate detection runs the deterministic and probabilistic matching described in Section 2.2 against new registrations.
- Reconciliation reports compare two systems and list what does not agree: scheduled appointments without encounters, encounters without charges, orders without results, interface messages sent without acknowledgment.
- Exception queues hold items that failed validation — unmatched documents, unindexed scans, unbilled encounters — and are worked to zero on a defined cadence.
The Rules of Engagement
The CEHRS exam tests judgment here more than technique. Four rules cover almost every scenario:
- Never alter another clinician's clinical documentation. A conflicting exam finding is queried and corrected by its author through an addendum or erratum, as described in Section 3.4. The specialist reports; the author corrects.
- Never merge or unmerge patient records. Duplicate and overlay resolution belongs to HIM, which reviews audit trails and moves clinical data safely. Front-line staff flag the suspected duplicate and stop.
- Fix demographic and coverage errors in the system of record. If registration data flows from the practice management system to the EHR, correcting it only in the EHR guarantees the error returns at the next interface refresh. Correct it at the source and let it propagate.
- Escalate anything that affects patient safety immediately. A missing result, a medication on the wrong chart, or an allergy that did not carry across an interface is not a ticket for tomorrow. It is a phone call now, followed by a ticket.
A Worked Example
The daily reconciliation report shows 42 completed appointments but only 39 encounters with charges. The specialist works the exception list:
- Encounter A — note is unsigned, so charges are held. Action: notify the provider to sign; the charge releases automatically (Section 8.2).
- Encounter B — the visit was documented under a patient with a nearly identical name and date of birth. Action: do not move the note. Report a suspected overlay to HIM immediately and notify the clinical manager, because the wrong chart now contains another patient's clinical data.
- Encounter C — the appointment was a no-show recorded as completed. Action: correct the appointment status in the scheduling module and document the no-show in the chart per Section 2.3.
Three discrepancies, three different owners, and only one of them is fixed by the specialist directly.
Documenting the Resolution
Every discrepancy that is reported should leave a trail containing:
- What was found, including the specific patients, encounters, or messages affected
- How it was detected (report name, queue, or observation)
- Who was notified and when
- What corrective action was taken and by whom
- Whether a root cause was identified and whether a preventive change was requested
That documentation is what turns individual fixes into the trend data quality committees use, and it is the evidence an auditor asks for when reviewing data integrity controls.
A registration specialist finds that a patient's insurance was updated in the practice management system but the EHR still shows the old plan. Where should the correction be made?
While reconciling encounters, a specialist discovers that a provider documented a full visit note in the chart of a different patient with a similar name. What is the correct immediate action?
Which validation technique would detect that a claim was submitted with a CPT code that was deleted before the date of service?