Your November MIPS Data Lock Needs a Change Log

The registry report looks ready. Then someone finds 60 missing encounters, and two people arrive at the review meeting with different versions of the “final” file.

Now you have two questions: Which records belong in the report, and which file reflects the latest review?

At Chirpy Bird, missing encounters and conflicting file versions recur. Here is how we recommend building a November MIPS review around a dated snapshot, source-to-report reconciliation, and a correction log that explains every material change.

Define exactly what your November data lock covers

A November data lock should establish a stable version for internal review. Give it a clear scope so nobody mistakes it for permission to stop collecting data.

CMS identifies January 1 through December 31, 2026, as the quality performance period. Continue full-year quality collection and reconcile later encounters before submission. Your internal November checkpoint does not replace that schedule. [1]

Start the review with a short record of what the snapshot represents:

  • Reporting entity: The individual clinician, group, or other reporting unit under review, including relevant TIN/NPI identifiers.

  • Coverage: Included locations, clinicians, measures, and collection type.

  • Dates: Service-date range, extraction timestamp, and registry processing cutoff.

Version: One unique file identifier and a named reviewer.


For example, a November 3 export might cover services through October 31. Label it accordingly. An export date alone cannot tell the next reviewer which encounters it contains.

Use a filename such as PY2026_GroupA_Quality_DOSthrough20261031_Export20261103_v1.0.csv. Keep patient identifiers out of filenames, and store the file in your approved secure location.

Preserve that snapshot as read-only. Route corrections into a new version instead of overwriting the evidence you started with.

Reconcile source totals before trusting the registry result

A registry report can look complete while a location, clinician, or batch of encounters never reached it. Start with the population you expected to send, then follow those records through processing.

Compare records at the same stage

Before comparing totals, align the service dates, reporting entity, location filters, and processing status. Check whether each report counts visits, patients, or measure-eligible cases. Those units can produce different totals without an error.

Ask for counts at each relevant stage:

  1. Records in the source extract.

  2. Records received by the registry.

  3. Records accepted, rejected, duplicated, or still pending.

  4. Cases that meet the selected measure's denominator criteria.

  5. Numerator results and applicable exclusions or exceptions.

Ingestion rejections and measure exclusions require different explanations. A formatting error may prevent processing. An exclusion must meet the measure's rules. Do not relabel a rejected record as an exclusion to make the totals reconcile.

Follow the missing encounters

Consider this hypothetical example, which does not describe a Chirpy Bird client:

Reconciliation stage Record count
Source extract for the defined population and dates 1,200
Registry receipt report for that same extract 1,140
Difference requiring investigation 60

The team traces the difference to a failed transfer from one location. After correcting the transfer, it verifies receipt, checks for duplicates, and accepts the revised totals.

That resolves the transfer gap. The team must still apply the measure's eligibility rules. The 1,200 source records are not automatically the measure denominator.

For unexplained measure-level differences, compare records individually. Check clinician attribution, service dates, and the fields supporting exclusions or exceptions against the applicable 2026 specification. CMS's Measure Explorer provides current specifications and reporting options. 

Give every material correction a traceable log entry

Once the team identifies a gap, record how it moves from discovery to verification. A change log should let another reviewer understand the correction without reconstructing an email thread.

Use one entry per issue or related batch. Include these fields:

Field What to record
Issue ID and discovery date A unique reference, such as NOV-004, and when the team found it
Original file Exact snapshot version and secure storage reference
Affected scope Clinicians, location, dates, measures, and record count
Finding and cause What differed and what the investigation established
Corrective action Transfer retry, mapping correction, or another documented action
Revised file New version, export timestamp, and processing status
Verification Before-and-after totals, duplicate check, and supporting report
Ownership and disposition Correction owner, reviewer, review date, and open or closed status

In the hypothetical example, NOV-004 would connect the 60-record transfer gap to the affected location, original file, transfer retry, and verified replacement version.

If the cause remains unknown, write “under investigation.” An incomplete investigation should remain visible.

Record what happened to the earlier file, too. Mark it as superseded for active review while retaining the original. Use the same version reference in meeting notes and vendor correspondence so everyone discusses the same evidence.

Keep record-level details in an access-controlled location. Your log can reference that location without copying patient information into a general project tracker.

Prioritize gaps by reporting impact and time to resolve

November leaves time for targeted corrections, but an undifferentiated issue list can consume it quickly. Assess each gap by how broadly it affects reporting and what it takes to resolve.

Use this internal triage approach:

  • Escalate promptly: A missing clinician or location, an unresolved transfer failure, or uncertainty about which file the team will submit.

  • Assign a focused review: Unexplained denominator movement, inconsistent exclusion logic, or repeated rejected records.

  • Complete routine cleanup: Labels or formatting that don't change record identity, calculations, or submission handling.

These are suggested operating priorities, not CMS categories.

Give every material issue an owner, a next action, and a due date. “Waiting on the vendor” needs a follow-up date and an escalation contact.

For a missing feed, send the vendor a concise evidence package: affected dates and location, expected and received counts, transfer reference, and a securely shared record sample when needed. Ask what failed, what will change, and how your team can verify the correction.

Close the issue when the evidence supports closure. A “fixed” message should trigger a new receipt or processing check, followed by reconciliation of the affected results.

Carry the review through December and final sign-off

Your November snapshot gives the team a starting point for later comparisons. Keep collecting December encounters and use the log to distinguish newly added records from corrections to earlier data.

Before each review, identify which version is current and list unresolved material issues. After the review, send a short recap naming the accepted version, outstanding corrections, and next check date.

Reconcile the final period before submission

After the performance year ends, account for encounters through December 31 and check for late documentation, delayed interfaces, or unprocessed records affecting the final reporting population. A technically accepted file still needs review of its scope and results.

Apply the same controls to the final file:

  • Confirm the reporting entity, measures, and full-year coverage.

  • Reconcile source records with registry processing and measure results.

  • Resolve material discrepancies and document any remaining limitations for review.

  • Record the final version, reviewer, approval date, and submission confirmation.

CMS requires clinicians and groups submitting MIPS information to certify that it is true, accurate, and complete to the best of their knowledge. They must retain that data and information for six years after the performance period ends. [2]

We help practices reconcile source data with registry results and identify reporting gaps. That work starts with locating the difference and establishing which records and file versions the team can support.

Your November data lock should give the team a stable review version and a clear account of subsequent changes. Keep full-year collection moving, verify material corrections, and carry that evidence into final sign-off.

If an encounter gap or conflicting file versions are holding up your review, book a strategy call with Chirpy Bird. Subscribe to Chirpy Bird's emails for practical MIPS guidance as you work through year-end reporting. Visit chirpybirdinc.com to connect with our team.

Sources

  1. CMS Quality Payment Program, Explore Measures & Activities, 2026 Quality Measures: https://qpp.cms.gov/reporting-requirements/measures-activities/explore

  2. 42 CFR 414.1390, Data validation and auditing: https://www.ecfr.gov/current/title-42/chapter-IV/subchapter-B/part-414/subpart-O/section-414.1390

Next
Next

When a MIPS Hardship Exception Is Appropriate: An Evidence-First Review