Quick answer
Evaluate an MDS update as several linked changes: the official manual and item sets, the vendor package, local templates and calendar rules, and records created under each version. Keep those identities separate. A useful release decision states which workflows passed, which assumptions remain unresolved, and what evidence will let staff revisit the decision after the next update.
Which MDS version applies in November 2026?
CMS lists RAI User’s Manual v1.20.11 as effective October 1, 2026. Its release hub also contains draft item sets v1.21.1 for October 1, 2027 and a November 3 notice about updated Appendix B contacts. These are different objects with different uses. A recently downloaded file is not necessarily the specification to use for an assessment. Check the CMS release notices when making the actual release decision.
The RAI manual separates assessment scheduling, item instructions and submission/correction guidance. This guide offers an original operational method for reviewing software changes; it does not choose an assessment type, ARD or coding response for a resident.
Keep four versions in the same ledger
A claim that software is current can conceal a mismatch between a correct vendor build and an outdated local report. Use a row for each affected workflow, not one row for the entire EHR.
| Layer | Record this evidence | Common mistaken conclusion |
|---|---|---|
| Official material | Title, version, effective context, source URL and date checked | Every file on the current CMS page is production guidance |
| Vendor implementation | Package/build, release notes, affected functions | Installation means every function uses the new logic |
| Local configuration | Template, calendar rule and interface versions | Local customizations automatically received the change |
| Record/output | Assessment identity, governing context, generated output version | Readability proves the historical meaning was preserved |
The ledger should preserve exceptions. An unresolved calendar issue should not be hidden by a successful form-display test.
A filled release decision
The following example is fictional. The package identifiers are invented; qualified MDS staff select the applicable records and expected behavior.
| Test | Observation | Decision |
|---|---|---|
| Current-context assessment in build N26.4 | Intended form and output context visible | Accept this tested path |
| Earlier assessment reopened after update | Original responses preserved; export labels only the new export engine | Request separate assessment-context metadata; historical output test open |
| Calendar entry after an administrative date correction | Main calendar updates; an already generated reminder retains its old date | Define supersession behavior and retest the reminder |
| Draft item set selected during ordinary work | Draft available without a distinct evaluation label | Restrict or clearly isolate draft use before acceptance |
The decision is not “three screens work, therefore approved.” The form path passed; historical output and reminder handling remain unresolved. That is enough information for a facility to negotiate a bounded release, request a repair or defer adoption under its approved process.
Explain calendar dates before trusting reminders
For a sampled calendar item, capture the triggering event, evidence for its date, assessment context, rule reference and qualified scheduling decision. The event date, ARD, completion date and transmission requirement are not interchangeable. The manual’s Chapter 2 and applicable item instructions supply the actual rules.
A useful diagnostic case is a hospital document uploaded Thursday that describes an event on Tuesday. If the calendar uses Thursday merely because it is the upload date, its precise deadline rests on the wrong input. Preserve the uncertainty and obtain the verified trigger; do not treat a software default as clinical interpretation.
When guidance changes, ask which existing entries are recalculated and which are flagged for review. Automatic recalculation reduces manual work but can change already communicated dates. Preserving all dates avoids silent changes but can leave obsolete reminders active. Either design needs an explicit review and supersession process.
Test history and recovery together
A rollback is not complete when an older package restarts. Identify records created after the update, outputs already distributed and unresolved corrections. Preserve the source and build context needed to decide what happens to that work.
Run the historical-record test through the actual export format used by the facility. An intact database value does not help a reviewer if a printed label changes its apparent meaning. Likewise, an export engine version can be accurate technical metadata while failing to identify the assessment specification.
For a multi-facility rollout, record actual use by site. Three facilities may have the build installed while only one has created records using the affected template. Repair scope should follow evidence of use and the defect, not installation count alone.
What to retain for the next update
Keep the ledger, a small synthetic test set, expected versus actual outputs and the signed local release decision together. Include the unaccepted cases and their repeat-test conditions. A replacement coordinator should be able to determine why the release was accepted without reconstructing the meeting.
This makes software evaluation actionable: the buyer can identify precisely which release responsibility belongs to CMS source monitoring, the vendor, local configuration staff or qualified assessment review.
Questions & answers
Does the newest file on the CMS page replace every earlier file?
No. The hub contains different artifacts, including future drafts and contact updates. Review the artifact type, effective context and applicable instructions before using it for assessment work.
What should an MDS update acceptance record contain?
Record the official reference, installed build, local configuration, dated test cases, actual outputs, unresolved issues and approval scope. Preserve evidence for historical records and calendar reminders as well as the current form.
Should a calendar use an uploaded document’s date as the triggering date?
Only when that timestamp actually represents the verified triggering event under the applicable instructions. Upload time alone establishes when a file entered the system; it does not establish when the underlying event occurred.
Primary sources
Use the cited source and its applicable version when making a facility-specific decision. These guides explain operational evaluation methods; they are not individualized clinical, coding, or legal advice.