MDS Submission Reconciliation: From iQIES Upload to Record Disposition

What does Completed mean in iQIES?

CMS’s iQIES Assessment Submitter Manual v2.2, pages 10–11, distinguishes a completed upload from acceptance of the assessment records. It describes record outcomes including accepted, rejected and duplicate and directs users to detailed submission information and the Final Validation Report (FVR). The manual is dated October 28, 2025; verify current QTSO instructions for actual screen and correction procedures.

This distinction changes the reconciliation task. A transport receipt answers whether a file arrived. The coordinator still needs to establish what happened to each assessment inside it.

Reconcile the intended population before the transmitted population

The following fictional reconciliation group has six intended assessments. Five entered facility-scoped exports; one remained outside them because a source question was unresolved. B17-N and B17-S are local export references, each linked to its own actual CMS submission identifier. The table combines their review; it does not prescribe combining facilities in one uploaded file.

All labels are synthetic. Do not submit test assessments to a production CMS system.

The accounting is six intended = five exported + one excluded. Within the five exported records, the ledger has two accepted outcomes, one rejected outcome, one duplicate outcome and one unlocated response. A warning is not a separate acceptance disposition; warning review is additional work attached to an accepted record. The missing local response is a reconciliation finding, not an invented CMS status.

Why equal counts can still be wrong

Suppose the local ledger imports five response rows, but two attach to North/0042/A1 and none attach to South/0042/A1. Five rows still match five exports. Identity-level reconciliation exposes the error.

Keep facility context and the source assessment identity through the match. A local record number alone may repeat across facilities. File names, row positions and resident display names are weak matching keys; renaming or sorting should not change the relationship.

For every matched record, retain the submission identifier, source assessment version, original response reference and review disposition. For an unmatched record, preserve the actual evidence and the investigation question rather than filling in the expected outcome.

A practical missing-response investigation

First establish that the assessment was included in the exported file, rather than merely intended for the batch. Next check the submission identity and facility context. In the cited v2.2 manual, section 3.6 directs the submitter from MDS Submission History to View Reports under Actions, opening My Reports and the FVR list. Match the Submission ID and facility context to the batch; confirm the current interface before following these version-specific steps. Finally reconcile the returned record identities to the local ledger.

This order prevents a common rework cycle: staff repeatedly look for a response to an assessment that never left the local queue. It also distinguishes a report-retrieval problem from a record rejection.

Do not retransmit the whole batch just to make the local dashboard green. The qualified submission owner must determine the correct next action using the applicable CMS guidance and observed dispositions.

Preserve corrections as a sequence

A corrected local display does not establish that CMS has the corrected record. Keep the original assessment, discovery date, reviewer’s decision, selected correction process, resulting export and later returned evidence connected.

Whether a record has already been accepted is a fact the reviewer needs before selecting the procedure. Use Chapter 5 of the applicable RAI manual, available through the CMS RAI manual hub, for the actual correction instructions. This ledger neither authorizes a change nor interprets a particular error code.

A review can appropriately end with no correction. Preserve that rationale too; otherwise the workflow rewards editing rather than explaining the record.

The handoff should expose remaining work

A backup should be able to identify A2’s warning review, A3’s rejected record, the duplicate relationship, the missing response and the excluded assessment separately. One “batch complete” checkbox cannot represent those states honestly.

For a software acceptance exercise, provide this six-record population and the response mismatch. Require the resulting ledger and original test outputs, not a salesperson’s narration. The buyer can then determine which stages the software automates, which need manual review and whether the actual coverage team has the access to finish them.