100-01 Medicare General Information, Eligibility and Entitlement Manual: Chapter 7 - Contract Administrative Requirements

General Information, Eligibility, and Entitlement
Manual
Chapter 7 - Contract Administrative Requirements
Table of Contents
(Rev. 13718; Issued: 04-10-26)
Transmittals for Chapter 7
10 - Contracting and Subcontracting – Not yet available
20 - Publishing by Contractors and Restrictions on Promotional Activity – Not yet available
30 - Records and Information Management Requirements and Responsibilities
30.10 - Records and Information Management Program
30.10.1 - Executive Order OMB M-23-07 Transition to Electronic Records
30.10.2 - Records Management Obligations
30.20 - Descriptions of Records
30.20.1 - Types of Record Schedules
30.20.2 - CMS Record Control Schedule
30.30 - Records Retention and Disposition
30.30.1 - CMS Records and Information Management Program Objectives
30.30.2 - Record Schedules Disposition Authority Numbered and Retention
Periods
30.30.3 - Records Dispositioning Process
30.40 - National Archives and Records Administration (NARA) Universal Electronic
Records Management (UERM) Requirements
30.40.1 - Information System Requirements
30.50 - Contract Initiation and Expiration
30.50.1 - General Security Requirements
30.50.2 - System Documentation
30.50.3 - Sanitization of Government File and Information
30.50.4 - Notification
30.50.5 - Contractor Responsibility upon Physical Completion of the Contract
30.50.6 - Records Management and Retention
30.60 - Litigation Hold Obligations
30.60.1 - CMS Contractor Litigation Hold Certification Requirements
30.70 - Digitization Requirements
30.70.1 - Digitization Standards

30.70.2 - Validation Requirements
30.70.3 - Disposal of Original Source Records
30.80 - Record Storage
30.80.1 - Commercial Storage Facilities
30.80.2 - Standards for All Record Storage Facilities
30.80.3 - Transfer of Federal Records stored in Commercial Facilities
30.80.4 - Commercial Storage Facilities Inspections
30.90 - Annual Reporting
30.90.1 - Annual Report on Medicare Records Requirements
30.100 - Exhibits
Exhibit A - CMS Certified and NARA approved Commercial Storage Facilities
Exhibit B - Annual Report Template
40 – Shared System Maintainer, Part A/Part B (A/B)/Durable Medical Equipment (DME)
Medicare Administrative Contractor (MAC) and the Single Testing Contractor (STC)
Responsibilities for System Releases
40.1 - Standardized Terminology for Claims Processing Systems
40.1.1 - Standard Terminology Chart
40.2 - Release Software
40.2.1 - Implementing Validated Workarounds for Shared System Claims
Processing by All Medicare Contractors
40.3 – Shared System Testing Requirements for Shared System Maintainers, Single
Testing Contractor (STC)/Beta Testers, and Part A/Part B (A/B) Durable Medical
Equipment (DME) Medicare Administrative Contractors (MACs)
40.3.1 - Shared System Testing Requirements for Shared System Maintainers,
Single Testing Contractor (STC), and DME MACs
40.3.2 – Minimum Testing Standards for Shared System Maintainers and the
Single Testing Contractor (STC)/Beta Tester
40.3.3 - Testing Standards Applicable to all Beta Testers
40.3.4 - Testing Requirements Applicable to the CWF Beta Tester
40.3.5 – Part A/Part B (A/B) Durable Medical Equipment (DME) Medicare
Administrative Contractor (MAC) (User) and the Single Testing Contractor
(STC) Testing Requirements
40.3.6 - Testing Requirements Applicable to all CWF Data Centers (Hosts)
40.3.7 - Timeframe Requirements for all Testing Entities
40.3.8 - Testing Documentation Requirements
40.3.9 - Definitions
40.3.10 - Test Case Specification Standard
40.3.11 - Single Testing Contractor (STC) Non-Testable Conditions and Potential

Testing Impacts
40.3.12 – Next Generation Desktop (NGD) Requirements
50 - Contractor Implementation of Change Requests and Compliance with Technical Direction
Letters
50.1 - CR Implementation Report (CRIR) Template
50.2 - TDL Compliance Report (TCR) Template
50.3 - Sample Cover Letter/Attestation Statement
50.4 - Change Request (CR) Definitions
50.4.1 - Issue Date
50.4.2 - Implementation Date
50.4.3 - Effective Date
50.4.4 - Date of Service
60 - Procedures for Modifying Shared System Edits and Capturing Audit Trail Data
60.1 - CMS Standard File for Reason Codes
70 - Change Management Process (Electronic Change Information Management Portal)
80 – Fee-For-Service Contractor Workload Transitions
80.1 – Transition Handbooks
90 - IDR Claims Sourcing from Shared Systems

30 - Records and Information Management Requirements and Responsibilities
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
CMS operates under the comprehensive records management framework established by the
National Archives and Records Administration (NARA). This framework includes compliance
with, but not limited to, The Federal Records Act (44 U.S.C. 21, 29, 31, and 33); NARA
regulations outlined in 36 Code of Federal Regulations (CFR) Chapter XII Subchapter B;
Privacy Act of 1974 safeguarding policies (5 U.S.C. 552a) for protecting Federal records. Under
the health insurance program, CMS bears the responsibility for developing and implementing
comprehensive standards for records and information management (RIM) programs. This
responsibility specifically includes key requirements to establish effective controls over record
creation processes, ensure records contain adequate and proper documentation of contractor
administration and operations, and to mandate that each contractor establish and maintain an
active RIM program.
Program Objectives: The RIM program shall provide economical and efficient management of
records as specified in §30.10 of this manual, ensuring both compliance with federal standards
and operational effectiveness.
Federal record means “…all recorded information, regardless of form or characteristics, made
or received by a Federal agency under Federal law or in connection with the transaction of
public business and preserved or appropriate for preservation by that agency or its legitimate
successor as evidence of the organization, functions, policies, decisions, procedures, operations,
or other activities of the United States Government or because of the informational value of data
in them.” (See 44 U.S.C. §3301).
(1) The term Federal record—
(i) Includes HHS/CMS records.
(ii) Does not include personal materials.
(iii) Applies to records created, received, or maintained on behalf of HHS/CMS by
contractors pursuant to their contract; and
(iv) May include deliverables and documentation associated with deliverables.
(2) Recorded information means all traditional forms of records, regardless of physical form or
characteristics, including information created, manipulated, communicated, or stored in digital
or electronic form. (See 44 U.S.C. 3301).
(3) Personal materials mean documentary materials belonging to an individual that are not used
to conduct agency business. Personal files are excluded from the definition of Federal records
and are not owned by the Government. (See 36 CFR 1220.18).
30.10 - Records and Information Management Program
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)

In accordance with the Code of Federal Regulations and 44 U.S.C. Chapter 31 § 3102
(Establishment of program of management), CMS bears the responsibility for establishing and
maintaining an active, ongoing program that ensures economical and efficient management of
agency records. This responsibility specifically requires CMS to implement effective controls
over the creation, maintenance, use, and disposition of records throughout current business
operations, while ensuring adequate and proper documentation of contractor administration and
operations. Additionally, each contractor shall establish and maintain their own active and
continuous program for economic and efficient records management as specified in §30 of this
manual. The program shall include, but is not limited to:
• Effective controls over the creation, maintenance, and use of records in the conduct of current
business.
• 	In accordance with 44 U.S.C. § 3102 and 36 CFR § 1220.34, establish comprehensive
controls over record lifecycle management throughout business operations
• 	Implement standardized procedures for record creation, classification, and ongoing
maintenance in accordance with NARA regulations at 36 CFR Chapter XII Subchapter B
• 	Ensure proper documentation of contractor administration and operational activities in
accordance with the Federal Records Act (44 U.S.C. 21, 29, 31, and 33)
• Procedures for identifying records of general interest or use to the public that are appropriate
for public disclosure, and for posting such records in a publicly accessible electronic format.
• 	In accordance with 5 CFR § 552 (Freedom of Information Act) requirements and
Executive Order 13392 on improving agency disclosure of information, develop
systematic procedures for identifying records suitable for public disclosure
• 	In accordance with 5 U.S.C. § 552(a)(2) and open government transparency mandates,
establish protocols for posting such records in publicly accessible electronic formats
• 	Maintain balance between transparency obligations and protection of sensitive
information as defined by FOIA exemptions in accordance with 5 U.S.C. § 552(b)
• Cooperation with CMS in applying standards, procedures, and techniques designed to improve
the management of records and information, promote the maintenance and security of records
deemed appropriate for preservation, and facilitate the segregation and disposal of records of
temporary value; and
• 	In accordance with 44 U.S.C. § 2904 and 36 CFR § 1220.18, provide full cooperation
with CMS in implementing records management standards and procedures
• 	In accordance with 36 CFR § 1236.10, actively promote maintenance and security of
records designated for preservation
• 	In accordance with NARA-approved disposition schedules and 36 CFR § 1226, facilitate
proper segregation and disposal of temporary records according to approved retention
schedules

• Compliance with sections § 30.10 – 30.100 of this manual.
• 	In accordance with the Federal Records Act (44 U.S.C. § 21, 29, 31, and 33), ensure
complete adherence to all provisions outlined in sections § 30.10 – 30.100 of this manual.
• 	In accordance with NARA regulations outlined in 36 CFR Chapter XII Subchapter B,
maintain compliance with federal records management laws
• 	In accordance with the Privacy Act of 1974 (5 U.S.C. § 552a) and 5 CFR § 552 (FOIA
requirements), integrate compliance requirements into all records management processes
to support open government transparency initiatives
These requirements align with the comprehensive records management framework established by
NARA and support CMS's responsibility for developing effective Records and Information
Management (RIM) programs under the health insurance program, while ensuring full
compliance with federal disclosure requirements and open transparency standards.
Records identified by CMS as pertaining to current or potential investigations, litigation, or
administrative actions, whether by the Office of Inspector General (OIG), Department of Justice
(DOJ), or any other relevant federal body, may not be destroyed or altered in accordance with
the Federal Records Act (44 U.S.C. Chapter 31) and applicable litigation hold requirements
under Federal Rule of Civil Procedure 37(e). This includes but is not limited to: records related
to ongoing Workers' Compensation claims, Medicare Secondary Payer (MSP) set-aside
arrangements, or those suspected of fraud, waste, abuse, or overutilization of services. These
records shall be retained in accordance with litigation hold requirements and shall not be
disposed of without explicit, written authorization from CMS, as failure to preserve relevant
records may result in sanctions under Federal Rules of Civil Procedure Rule 37(e) and potential
additional penalties under 18 U.S.C. § 1519 (obstruction of justice through destruction of
records in federal investigations).
Contractors shall ensure compliance with applicable federal records management requirements,
including electronic records standards, metadata integrity, secure storage, access controls, and
CMS-specific retention schedules and disposition authorities.
30.10.1 - Executive Order M-23-07 Transition to Electronic Records
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
Subject to the provisions of Executive Order M-23-07 Transition to Electronic Records, issued by
the Office of Management and Budget (OMB) and NARA, CMS, and thereby all contractors,
shall maintain a robust records management program that complies with the Federal Records
Act (44 U.S.C. Chapters 21, 29, 31, and 33) and its regulations codified in 36 CFR Chapter XII
Subchapter For purposes of this requirement, robust means a comprehensive, resilient, and fully
functional records management process or system that incorporates adequate controls, security
measures, and operational procedures capable of handling the complete lifecycle of federal
records while maintaining compliance with all applicable federal laws and regulations.

CMS contractors are required to establish and maintain an active and continuing program for
the economical and efficient management of the records outlined in §30.10 of this manual, in
accordance with 44 U.S.C. § 3102 (Establishment of program of management) and 36 CFR §
1220.34 (Agency records management program requirements). For purposes of this requirement,
cost effective means implementing records management practices that achieve maximum
operational efficiency and regulatory compliance while minimizing unnecessary expenditures,
utilizing appropriate technology solutions, and optimizing resource allocation to ensure
sustainable long-term records management operations.
The contractor's programs shall ensure that agency records are properly retained, stored, and
destroyed according to their disposition schedules. This includes but is not limited to:
• 	Ensure that all Federal records are created, retained, and managed in electronic formats,
with appropriate metadata.
• 	All permanent records shall be managed electronically, to the fullest extent possible, for
eventual transfer and accession by NARA in an electronic format. This does not apply to
permanent records accessioned into NARA or transferred for storage into Federal
Records Centers before June 30, 2024. After June 30, 2024, CMS will transfer permanent
records to NARA in electronic formats and with appropriate metadata, in accordance
with NARA regulations and transfer guidance.
• 	All temporary records in Federal agencies will be managed electronically, to the fullest
extent possible through the record’s disposition.
• 	Temporary, analog records that become eligible for transfer after June 30, 2024, shall be
transferred to commercial storage facilities that meet NARA records storage requirements
as specified in 36 CFR Part 1234. NARA will no longer accept transfers of permanent or
temporary records in analog formats and will accept records only in electronic format
and with appropriate metadata¹.
• 	Digitization of temporary analog records shall be made in accordance with NARA
regulations and guidance, including metadata requirements².
The contractor shall ensure the ongoing evaluation, enhancement, and compliance of record
classification and indexing systems to align with existing laws, regulations, or government-wide
policies, including but not limited to 36 CFR Part 1236 and guidance from NARA. The
contractor shall maintain records in an economic, secure, and efficient manner that ensures
accessibility, integrity, and reliability for agency operations and oversight.
30.10.2 - Records Management Obligations
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
A. Applicability1
1 NARA's metadata requirements for digitization are comprehensively outlined in 36 CFR Subpart E (Electronic
Records Management) and specifically detailed in NARA's guidance documents including "Metadata Guidance for

This clause applies to all Contractors whose employees create, work with, or otherwise handle
Federal records regardless of the medium in which the record exists.
B. Requirements
1. 	Contractor shall comply with all applicable records management laws and regulations,
as well as NARA records policies, including but not limited to the Federal Records Act
(44 U.S.C. Chapters. 21, 29, 31, 33), NARA regulations at 36 CFR Chapter XII
Subchapter B, and those policies associated with the safeguarding of records covered by
the Privacy Act of 1974 (5 U.S.C. § 552a). These policies include the preservation of all
records, regardless of form or characteristics, mode of transmission, or state of
completion.
2. 	In accordance with 36 CFR § 1222.32, all data created for Government use and delivered
to, or falling under the legal control of the Government are Federal records subject to the
provisions of 44 U.S.C. chapters 21, 29, 31, and 33, the Freedom of Information Act
(FOIA) (5 U.S.C. § 552), as amended, and the Privacy Act of 1974 (5 U.S.C. § 552a), and
shall be managed and scheduled for disposition only as permitted by statute or
regulation.
3. 	In accordance with 36 CFR § 1222.32, Contractor shall maintain all records created for
Government use or created in the course of performing the contract and/or delivered to,
or under the legal control of the Government and shall be managed in accordance with
Federal law. Electronic records and associated metadata shall be accompanied by
sufficient technical documentation to permit understanding and use of the records and
data.
4. 	CMS and its contractors are responsible for preventing the alienation or unauthorized
destruction of records, including all forms of mutilation. Records may not be removed
from the legal custody of CMS or destroyed except for in accordance with the provisions
of the agency records schedules and with the written concurrence of the Contracting
Officer and the Agency Records Officer. Willful and unlawful destruction, damage or
alienation of Federal records is subject to the fines and penalties imposed by 18 U.S.C. §
2701. In the event of any unlawful or accidental removal, defacing, alteration, or
destruction of records, Contractor shall report to CMS within 30 calendar days.
5. 	The Contractor shall immediately notify the appropriate Contracting Officer upon
discovery of any inadvertent or unauthorized disclosures of information, data,
documentary materials, records or equipment. Disclosure of non-public information is
limited to authorized personnel with a need-to-know as described in contracts awarded
by CMS Office of Acquisition & Grants Management (OAGM). The Contractor shall
ensure that the appropriate personnel, administrative, technical, and physical safeguards
the Transfer of Permanent Electronic Records" and related technical bulletins. For complete technical specifications
and implementation guidance, refer to 36 CFR § 1236.10 through § 1236.34 and current NARA bulletins available
at: https://www.archives.gov/records-mgmt/policy/transfer-guidance.html

are established to ensure the security and confidentiality of this information, data,
documentary material, records and equipment are properly protected. The Contractor
shall not remove material from Government facilities or systems, or facilities or systems
operated or maintained on the Government’s behalf, without the express written
permission of the Contracting Officer and Agency Records Officer. When information,
data, documentary material, records and/or equipment is no longer required, it shall be
returned to CMS control, or the Contractor shall safeguard it until otherwise directed.
records returned to the Government shall be hand carried, mailed via certified mail,
emailed, or securely electronically transmitted to the Contracting Officer or the Agency
Records Officer. Destruction of records is expressly prohibited unless in accordance with
Paragraph (4).
6. 	The Contractor (and any sub-contractor) is required to abide by Government and CMS
guidance for protecting sensitive, proprietary information, classified, and controlled
unclassified information.
7. 	The Contractor shall only use Government IT equipment for purposes specifically tied to
or authorized by the contract and in accordance with CMS policy.
8. 	The Contractor shall not create or maintain any records containing any non-public CMS
information that are not specifically tied to or authorized by the contract.
9. 	The Contractor shall not retain, use, sell, or disseminate copies of any deliverable that
contains information covered by the Privacy Act of 1974 or that which is generally
protected from public disclosure by an exemption or exclusion to the Freedom of
Information Act.
10. CMS owns the rights to all data and records produced as part of all contracts. All
deliverables under the contract are the property of the U.S. Government for which CMS
shall have unlimited rights to use, dispose of, or disclose such data contained therein as it
determines to be in the public interest. Any Contractor rights in the data or deliverables
shall be identified as required by FAR 52.227-11 through FAR 52.227-20.
11. Training. All Contractor employees assigned to CMS contracts who create, work with, or
otherwise handle records are required to take annual CMS provided records management
training. The Contractor is responsible for confirming training has been completed
according to agency policies, including initial training and any annual or refresher
training. All contractor employees who have access to (1) Department of Health and
Human Services (HHS) Federal Information or a Federal information system or (2)
personally identifiable information shall complete the CMS provided records
management training required by the Department of Health and Human Services (HHS)
before performing any work under their contract, and annually thereafter. The
Contractor shall also ensure any applicable subcontractor compliance with this training
requirement.

Contractor employees are expected to complete any new training requirements enacted by HHS
or CMS whereby access to the course material has been provided. These courses are at no
additional cost to the contract and the contractor is not required to provide documentation on
such training unless specifically requested. The Government does not anticipate a contractor to
develop a system specifically designed to track and monitor such trainings but will address the
requirements under overall contract management and adherence to regulations as noted in the
Contractor Performance Assessment Reporting System (CPARS).
Training Records. The contractor shall maintain training records for all its employees working
under this contract in accordance with HHS policy.
D. Flow-down of requirements to subcontractors
1. 	The Contractor shall incorporate the substance of this clause, its terms and requirements
including this paragraph, in all subcontracts awarded by CMS OAGM and require
written subcontractor acknowledgment of same.
2. 	Violation by a subcontractor of any provision set forth in this clause will be attributed to
the Contractor.
30.20 - Descriptions of Records
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
CMS Records Schedules ensure official CMS records, regardless of storage media, are preserved
appropriately to satisfy legal, fiscal, regulatory, and operational requirements while providing
economical and efficient records management in accordance with 44 U.S.C. § 3102 and 36 CFR
§ 1220.34.
30.20.1 - Types of Record Schedules
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
There are two types of records schedules, the CMS Records Control Schedule (RCS) approved by
CMS and NARA, and the General Records Schedule (GRS). These schedules provide mandated
instructions on the retention, transfer or destruction of records, documents, and materials. These
schedules are media and classification neutral unless otherwise specified.
30.20.2 - CMS Record Control Schedule
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
Effective 2017, CMS adopted a Bucket approach to records scheduling and disposition. These
records schedules identify the records accumulated by the contractor in administering the
Medicare program and outline the disposal schedule for each type of record. The approved
schedule provides disposition authority and instructions for program records and administrative
records not covered by the GRS. According to the disposition authority schedule for temporary
records, there are conditions when records are maintained for a longer period of time. See
section 30.60 ” Litigation Holds”.

BUCK
ET /
GRS
RECORD
SCHEDULE
NAME
DISPOSI
TION
AUTHOR
ITY
NUMBE
R
DESCRIPT
ION
RECORD
NAME/TYPE
FINAL
DISPOSI
TION
RETENT
ION
YEARS
DISPOSITI
ON
INSTRUCT
IONS
Bucke
t 2
Administr
ative
Managem
ent
DAA-
0440-
2015-
0002-
0002
Non-
substanti
ve
records
that
support
leadershi
p and/or
general
administr
ation of
all CMS
programs
. Includes
backgrou
nd files
related to
records in
other
buckets
as well as
records of
leadershi
p
positions
below the
Administr
ator and
other
principals
.
Medicare
Beneficiary
Correspondenc
e
Tempora
ry
3 	Cutoff at
the end of
the
calendar
year.
Destroy
no sooner
than 3
years
after
cutoff but
longer
retention
is
authorize
d.

BUCK
ET /
GRS
RECORD
SCHEDULE
NAME
DISPOSI
TION
AUTHOR
ITY
NUMBE
R
DESCRIPT
ION
RECORD
NAME/TYPE
FINAL
DISPOSI
TION
RETENT
ION
YEARS
DISPOSITI
ON
INSTRUCT
IONS
Bucke
t 3
Financial
Records
(Program
matic)
DAA-
0440-
2015-
0004-
0001
Financial
Records
(non-
GRS),
regardles
s of CMS
Program.
Includes
Medicare
Part A,
Part B,
Part C,
and Part
D;
Medicaid;
CHIP;
Affordabl
e Health
Care Act.
A/B MAC (A)
or HHH MAC FI
Billing
Records; A/B
MAC (B) or
DME MAC
Carrier Billing
Records;
Medicare
Benefit Check
Records ;
Reconsideratio
n and Hearing
Case Files -
Hospital
Insurance
Program
(Medicare
Appeals) ;
Review and
Fair Hearing
Case Files -
Supplementar
y Medical
Insurance
Program
(Medicare
Appeals) ;
MAC
Administrative
Budget
Estimate and
Cost Report
Form); Budget
request,
supplemental
budget
request, notice
Tempora
ry
7 	Cutoff at
the end of
the
calendar
year.
Destroy
no sooner
than 7
year{s)
after
cutoff but
longer
retention
is
authorize
d

BUCK
ET /
GRS
RECORD
SCHEDULE
NAME
DISPOSI
TION
AUTHOR
ITY
NUMBE
R
DESCRIPT
ION
RECORD
NAME/TYPE
FINAL
DISPOSI
TION
RETENT
ION
YEARS
DISPOSITI
ON
INSTRUCT
IONS
of budget
approval,
interim
expenditure
report;
Supplemental
Budget
Request;
Notice of
Budget
Approval –
The
carrier/interm
ediary’s
certified
funding
authority for
the fiscal year.
Include all
supporting
schedules,
correspondenc
e and
justification;
Interim
Expenditure
Report –
Cumulative
fiscal year to
date
expenditures
incurred by
the
carrier/interm
ediary. Include
all supporting
schedules,
correspondenc

BUCK
ET /
GRS
RECORD
SCHEDULE
NAME
DISPOSI
TION
AUTHOR
ITY
NUMBE
R
DESCRIPT
ION
RECORD
NAME/TYPE
FINAL
DISPOSI
TION
RETENT
ION
YEARS
DISPOSITI
ON
INSTRUCT
IONS
e and
justifications.;
Final
Administrative
Cost Proposal
– The final
statement of
expenditures
for the fiscal
year. This form
is used as the
basis for final
settlement of
allowable
costs. Include
all supporting
schedules,
correspondenc
e, HHS or GAO
audit reports
on
administrative
cost and
benefits
payments;
MAC Letter of
Credit Files );
A/B MAC (A)
or HHH MAC
Payment
Vouchers and
Transmittal
Files); A/B
MAC (B) or
DME MAC
Payment
Vouchers and
Transmittal

BUCK
ET /
GRS
RECORD
SCHEDULE
NAME
DISPOSI
TION
AUTHOR
ITY
NUMBE
R
DESCRIPT
ION
RECORD
NAME/TYPE
FINAL
DISPOSI
TION
RETENT
ION
YEARS
DISPOSITI
ON
INSTRUCT
IONS
Files); A/B
MAC (A) or
HHH MAC
Monthly
Financial
Report Files);
A/B MAC (B)
or DME MAC
Performance
Report Files);
A/B MAC (A)
or HHH MAC
Workload
Reports Files);
A/B MAC (B)
or DME MAC
Overpayment
and Duplicate
Charge
Detection
Activity Report
Files); A/B
MAC (A) or
HHH MAC Cost
Report Files);
MAC Closing
Agreements);
Medicare Data
Match Files);
Provider
Statistical and
Reimbursemen
t (PS&R) ); A/B
MAC (B) or
DME MAC
Claims
Processing File

BUCK
ET /
GRS
RECORD
SCHEDULE
NAME
DISPOSI
TION
AUTHOR
ITY
NUMBE
R
DESCRIPT
ION
RECORD
NAME/TYPE
FINAL
DISPOSI
TION
RETENT
ION
YEARS
DISPOSITI
ON
INSTRUCT
IONS
Bucke
t 4
Enrollmen
t Records
DAA-
0440-
2015-
0006-
0001
Enrollme
nt
Records
for all
CMS
Programs
. Includes
Medicare
Part A,
Part B,
Part
C, and
Part D;
Medicaid;
CHIP;
Affordabl
e Health
Care Act.
Initial
Enrollment
Questionnaire
Tempora
ry
7 	Cutoff at
the end of
the
calendar
year.
Destroy
no sooner
than 7
year{s)
after
cutoff but
longer
retention
is
authorize
d
Bucke
t 5
Beneficiar
y Records
DAA-
0440-
2015-
0007-
0001
Records
that
facilitate
the
manage
ment of
beneficiar
ies (those
eligible
for all
CMS
programs
)
Medicare
Summary
Notices
(MSNs)
Tempora
ry
10 	Cutoff at
the end of
the
calendar
year.
Retention
Period
Destroy
no sooner
than 10
year(s)
after
cutoff,
but
longer
retention
is
authorize
d

BUCK
ET /
GRS
RECORD
SCHEDULE
NAME
DISPOSI
TION
AUTHOR
ITY
NUMBE
R
DESCRIPT
ION
RECORD
NAME/TYPE
FINAL
DISPOSI
TION
RETENT
ION
YEARS
DISPOSITI
ON
INSTRUCT
IONS
Bucke
t 6
Provider
and
Health
Plan
Records
DAA-
0440-
2015-
0008-
0001
Records
related to
health
care
providers
affiliated
with CMS
programs
. Records
related to
health
care
providers
affiliated
with CMS
systems
and
programs
. Includes
provider
applicatio
ns and
certificati
ons;
health
plan
records;
program
review
and audit
records;
hearing
files; and
administr
ative
records.
Ambulance
Supplier
Certification
Files ;
Requests for
Assistance
from District
Offices (DOs)
Tempora
ry
7 	Cutoff at
the end of
the
calendar
year.
Retention
Period
Destroy
no sooner
than 7
year{s)
after
cutoff but
longer
retention
is
authorize
d,

BUCK
ET /
GRS
RECORD
SCHEDULE
NAME
DISPOSI
TION
AUTHOR
ITY
NUMBE
R
DESCRIPT
ION
RECORD
NAME/TYPE
FINAL
DISPOSI
TION
RETENT
ION
YEARS
DISPOSITI
ON
INSTRUCT
IONS
Bucke
t 9
Complianc
e and
Integrity
DAA-
0440-
2015-
0012-
0001
Records
that
support
complian
ce and
integrity
activities
and
functions,
regardles
s of CMS
Program,
including
plans,
agreeme
nts;
administr
ative
records,
records
related to
surveys,
reviews,
and
audits;
reports;
and legal
records
related to
complian
ce and
integrity
operation
s.
Contract
Performance
Review Visit
Files
Tempora
ry
7 	Cutoff at
the end of
the
calendar
year.
Retention
Period
Destroy
no sooner
than 7
year{s)
after
cutoff but
longer
retention
is
authorize
d

BUCK
ET /
GRS
RECORD
SCHEDULE
NAME
DISPOSI
TION
AUTHOR
ITY
NUMBE
R
DESCRIPT
ION
RECORD
NAME/TYPE
FINAL
DISPOSI
TION
RETENT
ION
YEARS
DISPOSITI
ON
INSTRUCT
IONS
Gener
al
Recor
ds
Sched
ule
(GRS
1.1) /
GRS
1.1,
ITEM
11
Financial
Managem
ent and
Reporting
Records
DAA-
GRS-
2013-
0003-
0002
This
schedule
covers
records
created
by
Federal
agencies
in
carrying
out the
work of
financial
manage
ment:
procuring
goods
and
services,
paying
bills,
collecting
debts,
accountin
g for all
financial
transacti
ons, and
monitorin
g
agencies'
net
worth. It
does not
apply to
copies of
records
forwarde
Procuring
goods 	and
services is the
acquisition 	of
physical
goods,
products,
personal
property, 	011
capital assets,
infrastructure
services 	such
as utilities, and
contracted
personnel
services to be
used 	by 	the
Federal
Government.
Paying 	bills
means
disbursements
of 	federal
funds 	for
goods 	and
services 	and
fulfilling
financial
obligations 	to
grant 	and
cooperative
agreement
recipients.
Procurement
and 	payment
records include
those such as:
contracts
Tempora
ry
1 	Destroy
when
business
use
ceases.

BUCK
ET /
GRS
RECORD
SCHEDULE
NAME
DISPOSI
TION
AUTHOR
ITY
NUMBE
R
DESCRIPT
ION
RECORD
NAME/TYPE
FINAL
DISPOSI
TION
RETENT
ION
YEARS
DISPOSITI
ON
INSTRUCT
IONS
d to the
Departm
ent of
Treasury
or the
Office of
Manage
ment and
Budget in
fulfillmen
t of
reporting
requirem
ents.
These
forwarde
d copies
serve
unique
business
purposes
at those
agencies
and are
therefore
scheduled
separatel
y as
records of
0MB and
Treasury
requisitions
purchase
orders
interagency
agreements
Military
Interdepartme
ntal 	Purchase
Requests
(MIPRs)
printing
requisitions to
the
Government
Printing Office
memoranda of
agreement
specifying 	a
financial
obligation
solicitations/re
quests for bids,
quotations 	or
proposals 	for
contracts 	and
competitive
grants
proposals,
quotations,
bids (accepted,
rejected,
unopened) for
contracts 	and
competitive
grants
contingent fee
justifications
legal 	and

BUCK
ET /
GRS
RECORD
SCHEDULE
NAME
DISPOSI
TION
AUTHOR
ITY
NUMBE
R
DESCRIPT
ION
RECORD
NAME/TYPE
FINAL
DISPOSI
TION
RETENT
ION
YEARS
DISPOSITI
ON
INSTRUCT
IONS
financial
instruments
such as bond
and 	surety
records 	FAIR
Act 	(A-76)
records 	linked
directly 	to
specific
procurement
actions 	credit
card/purchase
card/charge
card
statements
and
supporting
documentatio
n 	vendor 	tax
exemption
records
invoices leases
recurring
financial
transactions
such as utility
and
communicatio
ns 	invoices
documentatio
n 	of
contractual
administrative
requirements
submitted 	by
contractors
such as status
reports

BUCK
ET /
GRS
RECORD
SCHEDULE
NAME
DISPOSI
TION
AUTHOR
ITY
NUMBE
R
DESCRIPT
ION
RECORD
NAME/TYPE
FINAL
DISPOSI
TION
RETENT
ION
YEARS
DISPOSITI
ON
INSTRUCT
IONS
Correspondenc
e 	and 	papers
pertaining 	to
award,
administration
, 	receipt,
inspection 	of
and 	payment
for goods and
services in this
list records of
financing
employee
relocations

BUCK
ET /
GRS
RECORD
SCHEDULE
NAME
DISPOSI
TION
AUTHOR
ITY
NUMBE
R
DESCRIPT
ION
RECORD
NAME/TYPE
FINAL
DISPOSI
TION
RETENT
ION
YEARS
DISPOSITI
ON
INSTRUCT
IONS
GRS
5.2:
Item
020
Intermedi
ary
Records
DAA-
GRS-
2022-
0009-
0002
Intermedi
ary
records.
Records
that meet
the
following
condition
s: They
exist for
the sole
purpose
of
creating
a
subseque
nt record
and they
are not
required
to meet
legal or
fiscal
obligatio
ns, or to
initiate,
sustain,
evaluate,
or
provide
evidence
of
decision-
making.
This
includes
certain
analog
raw data used
to create final
print 	files;
Medicare
summary
notices,
standard paper
remittance
advices
Tempora
ry
1 	Destroy
upon
creation
or update
of the
final
record, or
when no
longer
needed
for
business
use,
whicheve
r is later.

BUCK
ET /
GRS
RECORD
SCHEDULE
NAME
DISPOSI
TION
AUTHOR
ITY
NUMBE
R
DESCRIPT
ION
RECORD
NAME/TYPE
FINAL
DISPOSI
TION
RETENT
ION
YEARS
DISPOSITI
ON
INSTRUCT
IONS
and
electronic
source
records
for
electronic
systems
that are
not
otherwise
excluded.
30.30 - Records Retention and Disposition
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
The CMS Records schedule identifies records accumulated by contractors in administering the
Medicare program and establishes disposition schedules for each record type. In accordance
with 44 U.S.C. § 3303a and 36 CFR § 1226, contractors shall actively manage federal records
disposition beyond storage and accessibility requirements.

30.30.1 - CMS Records and Information Management Program Objectives
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
In accordance with 44 U.S.C. § 2904 and 36 CFR § 1225.12, the CMS Records and Information
Management Program establishes retention schedules for all CMS records to provide uniform
guidelines for records retention and disposition; ensure compliance with legal, fiscal, and
regulatory requirements; authorize disposal of obsolete records; promote efficient records
management practices.
30.30.2 - Record Schedule Disposition Authority Numbers and Retention Periods
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
In accordance with 44 U.S.C. § 3303a and NARA-approved disposition authorities, Record
Schedule Disposition Authority Numbers provide legal citations for retention and disposition
authorizations for records created and maintained by CMS contractors supporting
administrative, legal, regulatory, personnel, operational, and fiscal activities. The retention
period refers to the legally mandated timeframe that records must be maintained before they are
eligible for disposition (transfer to NARA or destruction), which varies based on the record type
and its administrative, legal, or historical value. For example, Disposition Authority Number
DAA-0440-2013-0001-0002 might authorize the retention of contractor performance evaluation
records for seven years after contract completion before authorized destruction. No records shall
be destroyed without documented concurrence from the Contractor, the COR/RLO, and the CMS
Records Officer.
30.30.3 - Records Dispositioning Process
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
In accordance with 36 CFR § 1226.14 and as part of the Annual Report of Medicare Records,
each calendar year contractors must review their file plans, complete comprehensive records
inventories for both physical and electronic records, and identify records eligible for destruction.
CMS will provide a template for annual reporting purposes. Contractors are required to
complete an annual records management reporting process using CMS-provided templates. The
process involves submitting three completed worksheets through the Annual Report Template
(see Exhibit B), followed by a structured approval process that includes COR/RLO review with
Division Director authorization, CMS Records Retention mailbox submission, RIM staff
verification, and final CMS Records Officer approval. Once approved, contractors have 90 days
to begin project execution. Vendors have flexibility in scheduling the destruction of authorized
records but must maintain complete documentation of the destruction process. MACs shall
inform CMS upon completion of destruction projects, with details included in the annual report.
This streamlined system ensures federal compliance under 36 CFR regulations while
maintaining proper oversight of Medicare program records disposition, with the critical
requirement that no records may be destroyed without explicit CMS Records Officer approval.

Annual Review Requirements
In accordance with 36 CFR § 1226.14, at the beginning of each calendar year, contractors shall:
1. 	Review the FILE PLAN worksheet tab
2. 	Complete the RECORDS INVENTORY worksheet tab for all physical and electronic
records
3. 	Complete the REQUEST FOR RECORDS DISPOSAL worksheet tab listing records
eligible for destruction
4. 	Submit all worksheets in the Annual Report Template (Exhibit B). MACs must inform
CMS upon completion of destruction projects, with details included in the annual report.
Destruction Process
In accordance with 36 CFR § 1228.170(b):
1. 	Authorization Period: Once approved, contractors have 90 days to begin project
execution. MACs should inform CMS upon completion of destruction projects, with
details included in the annual report.
2. 	Documentation: Destruction supervisor shall document destruction date, signature,
official title, and return final authorization to CMS Records Retention mailbox.
30.40 - National Archives and Records Administration (NARA) Universal
Electronic Records Management (UERM) Requirements
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
The Universal ERM Requirements 2identify high level business needs for managing electronic
records. They are baseline ERM program requirements derived from existing statutes, standards,
NARA regulations, policy, and guidance. These requirements are based on the lifecycle of
electronic records management and include the following sections.
• 	Capture
• 	Maintenance and Use
• 	Disposal
• 	Transfer
• 	Metadata
• 	Reporting
2 NARA Universal Electronic Records Management (UERM) Requirements provide the framework for federal
agencies and their contractors to implement compliant electronic records management systems. These requirements
establish the minimum functionality needed for records management in federal information systems. The complete
UERM requirements can be accessed at: https://www.archives.gov/records-mgmt/policy/universal-erm-
requirements.

These requirements address born-digital and digitized analog records. The requirements are
either program requirements relating to the design and implementation of CMS’ Electronic
Records Management policies and procedures; or system requirements that provide technical
guidance in creating ERM tools and specifications for requirements a system will need to
manage electronic records.
30.40.1 - Information System Requirements
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
In accordance with OMB Circular A-130, paragraph 8a(1)(k), and HHSAR Part 304,
Administrative Matters (DEVIATION), Subpart 304.70, Records Management, contractors must
integrate comprehensive records management and archival functions into all information system
design, development, and implementation activities. This federal mandate requires contractors to
maintain the same rigorous records management standards as CMS, ensuring proper access,
maintenance, control, storage, disposition, and transfer capabilities for all records throughout
their lifecycle. Compliance with these requirements is a contractual obligation that supports the
integrity and accountability of Medicare program operations while meeting federal regulatory
standards for information governance. Refer to HHSAR Part 304, Administrative Matters
(DEVIATION). Subpart 304.70, Records Management for details. Legacy systems created before
the mandate are grandfathered and can use semi-automated or manual processes for records
management. MACs can manage records either through system functionality or manual methods
such as Excel spreadsheets, as long as records are categorized by type and year to determine
retention and eligibility for destruction.
30.50 - Contract Initiation and Expiration
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
Throughout the contract lifecycle, from initiation to expiration, contractors must maintain strict
adherence to information security, privacy requirements, and systematic documentation
standards to ensure seamless operations and proper contract closeout procedures. During
contract initiation, contractors establish foundational security protocols and system development
frameworks that must be sustained throughout the contract period, while contract expiration
requires comprehensive documentation transfer, systematic sanitization of all government
information and IT resources, proper disposal of records in accordance with federal guidelines,
and certification of data purging from contractor-owned systems. The transition process requires
proactive coordination with Contracting Officers (CO), Contracting Officer Representatives
(COR), and Information System Security Officers (ISSO) to ensure all government assets are
appropriately returned, all documentation requirements are fulfilled within specified timeframes,
and all security protocols are maintained until final contract closeout is completed, thereby
protecting sensitive government information while facilitating operational continuity.

30.50.1 - General Security Requirements
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
The Contractor shall comply with information security and privacy requirements, Enterprise
Performance Life Cycle (EPLC) processes, HHS Enterprise Architecture requirements to ensure
information is appropriately protected from initiation to expiration of the contract. All
information systems development or enhancement tasks supported by the contractor shall follow
the HHS EPLC framework and methodology or the CMS SDLC, as amended and in accordance
with the HHS Contract Closeout Guide (2012).
30.50.2 - System Documentation
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
Contractors shall follow and adhere to HHS/CMS System Development Life Cycle requirements,
at a minimum, for system development and provide system documentation at designated intervals
(specifically, at the expiration of the contract) within the EPLC and CMS SDLC that require
artifact review and approval.
30.50.3 - Sanitization of Government Files and Information
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
As part of contract closeout and at expiration of the contract, the contractor shall provide all
required documentation in accordance with the CMS SDLC, as amended to the CO and/or COR
to certify that, at the government's direction, all electronic and paper records are appropriately
disposed of and all devices and media are sanitized in accordance with NIST SP 800-88,
Guidelines for Media Sanitization.
30.50.4 – Notification
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
The Contractor shall continue to inform the CO, COR, and system ISSO as soon as possible
before an employee stops working under agency contracts. This notification process shall be
captured in the existing employee onboarding and offboarding enterprise system.
30.50.5 - Contractor Responsibilities upon Physical Completion of the Contract.
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
The contractor shall return all government information and IT resources (i.e., government
information in non-government-owned systems, media, and backup systems) acquired during the
term of this contract to the CO and/or COR. Additionally, the contractor shall provide a
certification that all government information has been properly sanitized and purged from
Contractor-owned systems, including backup systems and media used during contract
performance, in accordance with HHS and/or CMS policies.

30.50.6 - Records Management and Retention
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
The contractor shall maintain all information in accordance with Executive Order 13556 -
Controlled Unclassified Information, National Archives and Records Administration (NARA)
records retention policies and schedules and HHS Policy for Records Management and CMS
policies and shall not dispose of any records unless authorized by HHS/CMS. If a contractor
accidentally disposes of or destroys a record without proper authorization, he/she shall
document and report the incident to the CMS Agency Records Officer and RIM staff in
accordance with HHS/CMS policies.
30.60 - Litigation Hold Obligations
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
A litigation hold is a notification to recipients to retain information in the agency's possession,
custody, or control relevant to those claims or defenses. When CMS reasonably anticipates
litigation or litigation has commenced, CMS has a duty to take reasonable steps to preserve
information relevant to any party's claims or defenses at issue in a manner that is proportional to
the needs of the case. In accordance with (Fed. R. Civ. Pro. 26(b)(1), 37(e)), contractors shall
personally take appropriate steps to preserve any responsive information that is in their
possession, custody, or control. Accordingly, until notified otherwise, contractors shall preserve,
and refrain from discarding, any and all responsive information related to a litigation hold. Steps
shall be taken to suspend routine document retention, destruction policies and practices,
including, but not limited to, those in the records schedule. Contractors must maintain strict
confidentiality of litigation hold communications and may not share litigation hold information
with external parties, including grantees, nonprofits, advocacy groups, legal representatives,
providers, or suppliers.
Preservation shall occur even if the information sought may ultimately be withheld as privileged,
protected, classified, or confidential, or determined to be unreasonably burdensome to produce.
If information subject to a litigation hold is destroyed, a court may impose sanctions, including
the exclusion of evidence, the dismissal of a claim, the production of privileged information,
and/or award costs and attorney fees against the government. When transferring responsibilities
or ending CMS relationships, contractors must consult with the Contracting Officer's
Representative (COR) and follow established litigation records management procedures to
ensure continuity of litigation hold compliance and proper transfer of preserved documents.
Documents include all forms of written material, whether in final or draft form, original or
duplicates, complete or partial, official or unofficial. Examples include memoranda, reports,
printed emails, maps, diagrams, correspondence, spreadsheets, presentation materials, and notes
(including handwritten notes). Hardcopy documents shall be preserved even if they are
duplicative of electronically stored information.
The types of information related to the categories that shall be preserved include the following:
A. 	Electronically Stored Information (ESI): Information that is stored electronically,
regardless of the type of media, as opposed to information that is stored in hard copy

(i.e., on paper). ESI includes, but is not limited to, word processing files, e-mail
messages, archived e-mails, metadata, text messages, other electronic communication
including voicemail, telephone log entries, databases, scanned/static images (PDFs or
TIFFs), Internet usage files, systems manuals, network access information, drafts,
spreadsheets, data, PowerPoint presentations, calendar entries, address books, digital
photographs or other digital images, audio recordings, floppy discs, CDs, DVDs, and
flash memory media, including USB drives and memory cards for cameras and cell
phones. ESI should be preserved in its originally created or native format. This
information includes not only content stored on HHS computers, but can also include
information stored on home computers, personal laptop computers, personal e-mail
accounts, and PDAs or mobile phones such as Blackberries, iPhones, and Androids, if
used for work. ESI shall be preserved even if it is duplicative of hardcopy documents.
B. 	Metadata: Data typically stored electronically that describe characteristics of ESI, such
as how ESI is formatted, or how, when or by whom ESI is collected, created, accessed, or
modified. Metadata can be supplied by applications, users, or the file system.
C. Tangible Things: Tangible things are items that are likely to have discoverable
information such as equipment, laboratory samples, specimens, and photographs.
30.60.1 - CMS Contractor Litigation Hold Certification Requirements
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
When a Contractor receives a CMS Litigation Hold Memorandum from their contracting officer, the
Contractor must immediately implement the litigation hold requirements and provide certification of
compliance. The memorandum will be shared with Contractors when CMS components identify that the
Contractor may possess potentially responsive documents relevant to ongoing or anticipated litigation.
Upon receipt of the litigation hold memorandum, Contractors must follow these steps:
• 	Immediately suspend all routine destruction or disposal of potentially responsive documents
• 	Notify relevant personnel within the Contractor's organization about the litigation hold
requirements
• 	Implement preservation measures for all identified document categories and types
• 	Conduct a comprehensive search for potentially responsive documents across all systems and
storage locations
• 	Maintain detailed records of all preservation actions taken
• 	Provide written certification to CMS confirming implementation of the litigation hold by
completing and signing the CMS Contractor Litigation Hold Certification & Information Form
• 	Provide names of identified litigation hold custodians within their organization to the COR
• 	Report any challenges or issues in implementing the hold to the CMS contracting officer
Contractors must ensure full compliance with the litigation hold requirements until formally notified by
CMS that the hold has been lifted. Failure to properly implement and maintain litigation hold
requirements may result in legal consequences and potential contract violations.

30.70 - Digitization Requirements
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
In accordance with 84 FR 14266 (April 10, 2019) and federal regulations, CMS contractors must
follow specific requirements when digitizing temporary federal records to ensure compliance
with records management standards and facilitate the transition to electronic recordkeeping
systems.
In accordance with 36 CFR § 1236.32 and § 1236.34, contractors must meet all required
digitization standards before designating digital versions as recordkeeping copies, validate the
digitization process through documented procedures, and capture complete information from
original source records including all pages and components. This comprehensive approach
ensures that the digitized records maintain the integrity and completeness of the original
documents while meeting federal regulatory requirements for electronic recordkeeping systems.
As a CMS contractor, if you intend to digitally reproduce (digitize) temporary records to
designate the digitized version as the recordkeeping copy and destroy the original source
records, you shall:
1. 	In accordance with 36 CFR § 1236.32, digitize the records to meet all required standards
2. 	In accordance with 36 CFR § 1236.34, validate the digitization process
When the digitized version becomes the designated recordkeeping copy, the original source
record is reclassified as an intermediary record. You may dispose of these intermediary records
in accordance with 36 CFR § 1236.36 and General Records Schedule (GRS) 5.2.
30.70.1 - Digitization Standards
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
When digitizing temporary records, you shall meet the following standards in accordance with
36 CFR § 1236.32:
1. 	Capture all information contained in the original source records
2. 	Include all pages or parts from the original source records
3. 	Ensure the digitized versions can be used for all purposes the original source records
serve, including the ability to attest to transactions and activities
4. 	Implement protections against unauthorized deletions, additions, or alterations to the
digitized versions
5. 	Ensure the digitized versions can be located, retrieved, accessed, and used throughout
their entire retention period
30.70.2 - Validation Requirements
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)

In accordance with 36 CFR § 1236.34:
1. 	You may establish your own validation process or utilize third-party processes to validate
that digitized versions comply with the standards in 36 CFR § 1236.32
2. 	You shall document your validation process and retain that documentation for the life of
the process or the life of any records digitized using that process, whichever is longer
3. 	Be aware that CMS and/or NARA may review your validation documentation as needed
30.70.3 - Disposing of Original Source Records
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
After successful digitization and validation:
1. 	In accordance with General Records Schedule (GRS) 5.2 and 36 CFR § 1236.36, you
may destroy the original source records after digitization, subject to any pending legal
constraints such as litigation holds
2. 	You shall treat the digitized versions (now the recordkeeping versions) with the same care
and retention requirements as the original source records
3. 	You shall retain the digitized versions for the remaining portion of any retention period
established by the applicable records schedule
4. 	You do not need to obtain CMS or NARA approval to destroy scheduled temporary
records that have been properly digitized according to these requirements
This guidance ensures your compliance with federal records management regulations while
facilitating the transition to electronic recordkeeping systems.
30.80 - Record Storage
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
CMS has established comprehensive requirements for contractors utilizing commercial storage
facilities to house Federal records. Under federal regulations 44 U.S.C. § 3102 and 36 CFR §
1220.34, contractors bear the same responsibility as CMS for ensuring all records in their
physical custody are stored in appropriate facilities that meet federal standards. These
requirements mandate that contractors ensure any commercial vendor housing Federal records
be approved by CMS and certified by the National Archives and Records Administration (NARA)
in accordance with 36 CFR § 1234.12 and § 1234.30. The requirements include facility
structural standards, environmental controls, fire safety measures, and comprehensive
documentation processes, including mandatory submission of inspection checklists and
certification letters to the CMS Records Officer at Records_Retention@cms.hhs.gov at least 120
days before transferring records. Additionally, NARA has the authority to conduct periodic
inspections of commercial facilities and specific procedures are outlined for facility transfers,

ensuring that all Federal records remain protected and accessible while maintaining compliance
with federal records management regulations throughout their lifecycle.
30.80.1 Commercial Storage Facilities
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
In accordance with 44 U.S.C. § 3102 and 36 CFR § 1220.34, CMS contractors are responsible
for ensuring that all records in their physical custody are stored in appropriate space.
Contractors shall adhere to the same requirements as CMS for records storage and management.
Records centers and commercial records storage facilities are referred to collectively as records
storage facilities. In accordance with 36 CFR § 1234.30, contractors may contract for
commercial records storage services. However, before any agency records are transferred to a
commercial records storage facility, contractors shall ensure that the facility meets all the
requirements for an agency records storage facility set forth in subpart § 1234.30 and shall
submit the required documentation to CMS. Contractors must verify facilities meet NARA
standards, maintain contact information, and obtain certification copies, with inspections
conducted by NARA every five years. contractors shall obtain and maintain copies of NARA
inspection certifications from commercial storage facilities, ensuring compliance with CFR 1234
standards and annual updates of contact information.
In accordance with 44 U.S.C. § 2904 and 36 CFR § 1234, NARA is authorized to promulgate
standards, procedures, and guidelines to Federal agencies and their contractors with respect to
the storage of records in commercial records storage facilities. NARA initiates facility
inspections on a rotating five-year basis, and contractors are responsible for ensuring their
facilities remain compliant and up to date with fire safety and climate control requirements.
30.80.2 - Standards for All Records Storage Facilities
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
A facility that is used to store Federal records, shall meet the minimum structural,
environmental, property and fire safety standards as outlined in 36 CFR Part 1234 Facility
Standards for Records Storage Facilities. The facility shall be constructed with non-combustible
materials and building elements, including walls, columns and floors. CMS is responsible for
ensuring that records in their legal custody are stored in appropriate space as outlined in this
part. Under § 1232.18(a), agencies are responsible for initiating action to remove records from
space that does not meet these standards if deficiencies are not corrected within 6 months after
initial discovery of the deficiencies by NARA or the agency and to complete removal of the
records within 18 months after initial discovery of the deficiencies.
To store Federal records in a commercial records storage facility, you shall document that the
facility meets the 36 CFR 1234 storage standards. You shall submit a Facility Standards for
Record Storage Facilities Inspection Checklist (see Exhibit A) for all records storage facilities
used to store CMS records to the CMS Records Officer at Records_Retention@cms.hhs.gov .

30.80.3 - Transfer of Federal Records stored in Commercial Facilities
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
If you are planning to relocate any Federal records to a different approved storage facility,
provide the following information at least 120 days prior to the move date to the CMS Records
Officer at: Records_Retention@cms.hhs.gov
• 	Move date,
• 	Name of the old and the new storage facility and address
• 	Rough volume figure of how many cubic feet of records are involved.
The contractor shall provide documentation demonstrating that the commercial facility meets the
storage standards set in 36 CFR 1234 before beginning to transfer records to a commercial
records storage facility,. Submit separate documentation for each individual facility that you will
use. Contractors using a commercial vendor or planning to move records from one commercial
facility to another that has not been certified and approved, shall complete the three documents
listed below and submit to the CMS Records Officer at Records_Retention@cms.hhs.gov.
• 	Inspection Checklist for Records Storage Facilities,
• 	Certification letter from a Fire Protection Engineer and a Structural Engineer § 1234.12
What are the fire safety requirements that apply to records storage facilities, and
• 	Description and volume of records
Once certified and approved, you will receive notification that the facility is approved, and that it
will be added to the list of approved facilities
30.80.4 - Commercial Storage Facilities Inspections
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
NARA is authorized to conduct periodic inspections of any commercial records storage facility
used by CMS and its contractors for compliance with the 36 CFR 1234 Facility Standards for
Records Storage Facilities.
1234.10(c): FEMA 100-year flood map (available at https://msc.fema.gov/portal/search)
1234.10(d): Appendix A (S4): AHJ Fire Marshall and/or Fire Department Inspection
1234.10(j): UL (Burglar) Alarm Central Monitoring Certificate
1234.10(k): Appendix A (S3): Security System Inspection
1234.10(m): Integrated Pest Management (IPM) service Inspection
1234 Appendix B (2b) & (2f): Annual Sprinkler System & Fire Alarm Inspections
Upon request from the CMS RIM Staff, Contractors shall provide the Point of Contact for the
commercial records storage facility prior to the inspections for coordinating scheduling the

inspections and providing an updated Facility Standards for Records Storage Facilities
Inspection Checklist for each facility.
30.90 - Annual Reporting
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
Contractors are required to comply with the Annual Report of Medicare Records Requirements outlined in
section 30.90 of this manual. This mandatory annual reporting process ensures that proper records
management practices are maintained and meet federal regulatory compliance standards. At the
beginning of each calendar year, contractors must conduct a comprehensive assessment of their records
inventory and submit detailed file plans to CMS at Records_Retention@cms.hhs.gov. The contractor's
assessment must cover all official records under their management, including those stored in electronic
systems, databases, and commercial storage facilities, with special attention to identifying and protecting
personally identifiable information (PII) and protected health information (PHI). Contractors are
responsible for documenting all record categories, retention schedules, storage locations, and volume
assessments according to both CMS Records Schedule requirements and NARA General Record Schedule
guidelines. This annual reporting requirement helps contractors maintain organized records management
practices while supporting CMS's oversight responsibilities and ensuring the integrity and accessibility of
records under the Contractor’s stewardship.
30.90.1 Annual Report of Medicare Records Requirements
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
Medicare contractors shall submit an Annual Report of Medicare Records at the beginning of
each calendar year using the required Annual Report of Medicare Records template provided by
CMS (see Exhibit B). Contractors must utilize the current template format specified by CMS to
ensure standardized reporting and compliance with federal records management standards. The
completed template must include all mandatory components and documentation as outlined in
the provided format, and submissions that do not use the required template may be rejected or
returned for correction.:
Required Components
1. 	Records Inventory
o 	Complete review of all official records
o 	Electronic storage locations
o 	Commercial storage facilities
o 	Volume assessment
o 	PII/PHI identification
o 	Essential records designation
o 	Special access requirements
2. 	File Plan
o 	Use current template

o 	Record categories and types
o 	Retention schedules
o 	Location details
o 	Volume information
Process Steps
1. 	Review and Assessment
o 	Consult CMS Records Schedule
o 	Review NARA General Record Schedule
o 	Document all storage locations
o 	Identify sensitive information (PII/PHI)
2. 	Verification Checklist
o 	Complete records categories
o 	Accurate retention schedules
o 	Current storage locations
o 	Updated volume of information
o 	Correct file plan template
Submission
• 	Due: Start of calendar year
• 	Submit to: Records_Retention@cms.hhs.gov
• 	Format: Current Annual Report template
• 	Include: Complete inventory and file plan
This annual report ensures proper records management and compliance with federal regulations
while maintaining accurate tracking of Medicare records across all storage locations.
30.100 	Exhibits
(Rev. 13718; Issued: 04-10-26; Effective: 05-11-26; Implementation: 09-14-26)
30.100.1 Exhibit A. CMS-Certified and NARA-Approved Commercial Storage Facilities
30.100.3 Exhibit B. Annual Report Template

CMS Contractor Litigation Hold Certification & Information Form for
[Insert Case Name]
I. CERTIFICATION
I declare that, to the best of my information and belief, I have caused all appropriate personnel of
[insert name of CMS Contractor], including (but not limited to) those listed in Section II below,
to become aware and informed that (i) a Litigation Hold exists in the above-captioned matter; (ii)
this Litigation Hold imposes an ongoing duty to preserve and retain certain documents, records,
data, or files, whether maintained electronically or in hard copy, pertaining to the above-
captioned matter, and that are within the categories of information to be preserved, and (iii) this
Litigation Hold remains in effect until expressly advised by CMS that this litigation hold has
been lifted.
__________________________________________
______________________________________
Printed Name/Title 	Signature
________________________________
______________________________________
Contract 	Executed on date
II. INFORMATION ON POTENTIAL DOCUMENT CUSTODIANS
Please list the names and contact information (telephone numbers and e-mails) of all
individuals within your organization whom you have identified as potentially having responsive
information in their possession, custody, or control for this litigation hold. If you do not believe
your organization has potentially responsive information in its possession, custody, or control,
please note this in the space provided below with a brief explanation. Please attach additional
paper if needed.
This completed original form must be returned {SELECT ONE}[within fifteen business days of
the issuance date of this TDL in PDF file format] [by {insert date two weeks from notice}] to:
[Insert full contact information for COR]
NOTE: The requirements of this litigation hold are continuing; if you learn of any new
individuals who have potentially responsive information, or if any named custodian is leaving
your organization, please notify the OGC attorney for this litigation hold: [Insert name and
email address of OGC attorney]

40 – Shared System Maintainer, Part A/Part B (A/B)/Durable Medical
Equipment (DME) Medicare Administrative Contractor (MAC) and the
Single Testing Contractor (STC) Responsibilities for System Releases
(Rev. 97, Issued: 01-15-16, Effective: 09-21-15, Implementation: 09-21-15)
40.1 – Standardized Terminology for Claims Processing Systems
(Rev. 97, Issued: 01-15-16, Effective: 09-21-15, Implementation: 09-21-15)
(Rev. 105 , Issued: 06-02-17, Effective: 07-03-17, Implementation: 07-03-17 )
The SSMs, MACs and the STC shall use standardized terminology to refer to common systems
maintenance elements in all discussions, reporting, and documentation. Using common
terminology will minimize confusion and misunderstanding for CMS, SSMs, MACs and the
STC. The MACs and the STC shall examine their use of the system status information issued by
the SSMs to determine if they have internal applications that need to be adjusted to adopt the
standardized terminology. If they have internal systems or processes that must be modified to
reflect the standardization required by this instruction, they shall make those changes to coincide
with the shared system changes.
40.1.1 - Standard Terminology Chart
(Rev. 105, Issued: 06-02-17, Effective: 07-03-17, Implementation: 07-03-17)
STANDARD TERMINOLOGY 	DESCRIPTION
QUESTION (QCN) 	Request for assistance and/or reported potential system
problem. For questions, the MACs and the STC shall
contact the SSM’s helpdesk to log their question.
PROBLEM 	Confirmed system and/or documentation problem
Change Request (CR) 	Any software modification made to the system as a
result of a CMS mandate or maintainer initiated action
CMS STATUS 	CMS needs take action by answering a question,
finalizing an instruction, etc.
NSC (non-system change) STATUS 	CMS CR does not require shared system change. May
require A/B MAC maintenance
RESEARCH STATUS 	The SSM completes high level review of required
changes by analyzing them and determining the intent
of the change request

REQUIREMENTS (REQS) STATUS 	The SSM finalizes the business requirements
WALKTHROUGH STATUS 	The SSM presents the systems solution to the CR in a
structured walkthrough discussion with CMS and Beta
testers
WORK STATUS 	The SSM completes technical design, coding and unit
testing the system change

STANDARD TERMINOLOGY 	DESCRIPTION
ALPHA TESTING 	Functional testing performed by the SSM, after
successful unit testing of the new or modified code;
which starts approximately ninety (90) days prior to
the implementation of the Change Request. The testing
verifies all changed components function appropriately
within the full environment at the SSM site in a
controlled environment.
BETA TESTING 	This is the second phase of testing after Alpha testing.
The goal of Beta testing is to identify and resolve any
remaining defects before a product/software is released
to a production environment. Beta testing begins eight
weeks prior to the production implementation date of a
quarterly release. The Beta tester continues to test all
iterations of the code through the UAT testing phase
until the release moves to production. The Beta tester
continues to test for two weeks post production or until
they are 100% completed, whichever comes first.
User Acceptance Testing (UAT) 	MACs and DME MACs perform UAT testing during
the four weeks prior to the production implementation
date of a quarterly release.
USER STATUS 	The SSM returns question to user to provide more
information or examples, assess solution
40.2 - Release Software
(Rev.: 128, Issued: 11-01-19, Effective: 12-03-19, Implementation: 12-03-19)
Shared System Maintainers (SSMs) shall obtain approval from their Government Task Leader
(GTL) before quarterly release software can be scheduled and installed.
Control of System Changes
SSMs shall use the same quarterly release schedule, (i.e., on or about October 1, January 1, April
1, and July 1). CMS will schedule each quarterly release.
All follow-up release changes (except emergencies) to the quarterly schedule shall be held and
released on a predetermined schedule in coordination with CMS. Unscheduled emergency
changes released as problems are identified without prior approval. The schedule for a follow-up
release of changes shall be forwarded to your GTL for prior approval.

When a system problem is identified, Medicare contractors (i.e. SSMs, the STC, MACs and
CWF Hosts) shall submit documentation to their GTL outlining the problem and the reason
correction is needed at this time. Section V of this instruction outlines the minimum information
required by CMS for approval.
Problem Priority Classifications for Follow-Up Releases
Listed below are CMS’s problem priority classifications and examples.
Priority 1 Classification
Production:
The problem prevents the accomplishment of a mission critical capability for which no
acceptable workaround is known.*
This priority also includes problems where code shall be fixed immediately in order for the
normal production region functions or services to continue. For example, if the production
region is down in a job resulting in an incomplete cycle or the system is pricing a
significant volume of claims incorrectly causing over or under payment. These corrections
shall be reported to the GTL the next business day.
EXAMPLES:
• 	ABENDS on-line or batch (Inability to run a cycle)
• 	Inaccurate payment or no payment of claims (significant impact/high volume)
• 	Necessary file updates cannot be accomplished (payment files, history files)
• 	Interface failures affecting claims processing
Beta/User Acceptance Testing:
The problem would prevent the accomplishment of a mission critical capability if the
current test software is moved into the production environment. This priority also includes
problems where code shall be fixed immediately in order for the normal test region
functions or services to continue. For example, if the test region is down in a job causing
the cycle to not complete or the system is pricing claims incorrectly with a potentially
significant claim volume or payment impact, the issue would be classified as a priority 1.
EXAMPLES:
• 	ABENDS; inability to run a cycle or test
• 	Inaccurate payment or no payment of claims (potentially significant impact)

• 	Necessary file updates cannot be accomplished (payment files, history files)
• 	Interface failures affecting test conditions
Priority 2 Classification
Production:
The problem adversely affects the accomplishment of a mission critical capability so as to
degrade performance and for which no acceptable work-around is known.* This means the
problem adversely affects the payment of benefits with a small claim volume or payment
impact, the completion of CMS required reporting, or inaccurate information is being sent
providers, beneficiaries or CMS. For example, if the information on an outgoing document
to the provider community or Medicare Summary Notice is incorrect, the issue would be
classified as a priority 2.
EXAMPLES:
• Inaccurate payment or no payment of claims (small impact/low volume)
• Inaccurate CMS required report
• Inaccurate messages to the beneficiary, provider or CMS
• ABENDs with limited impact (e.g. one contractor)
Beta/User Acceptance Testing:
The problem would adversely affect the accomplishment of a mission critical capability so
as to degrade performance if current test software is moved into the production
environment. This means the problem adversely affects the payment of benefits with a
potentially small claim volume or payment impact, the completion of CMS required
reporting, or inaccurate information is being sent to providers, beneficiaries or CMS. For
example, if the information on an outgoing document to the provider community is
incorrect, the issue would be classified as a priority 2.
EXAMPLES:
• Inaccurate payment or no payment of claims (potentially small impact)
• Inaccurate CMS required report
• Inaccurate messages to the beneficiary, provider or CMS

Priority 3 Classification
Production:
The problem adversely affects the accomplishment of mission critical capability so as to
degrade performance and for which an acceptable workaround is known.*
This means the problem could have significant impact but the work-around alleviates the
impact. This allows the system maintainer adequate time to code a fix and sufficiently test
before the corrected software is delivered for production installation.
EXAMPLES:
• 	Impact of problem could be significant or minimal
• 	Problem correctable by contractor workaround*
• 	ABENDs with an acceptable workaround*
Beta/User Acceptance Testing:
The problem would adversely impact the accomplishment of a mission critical capability so
as to degrade performance if current test software is moved into the production
environment.
If moved into the production environment before correcting an acceptable workaround
could be instituted to prevent the adverse impact. **
EXAMPLES:
• 	Potential impact of problem could be significant or minimal
• 	Problem affects CMS required reporting
Priority 4 Classification
Production:
The problem is an operator inconvenience or annoyance, which does not affect a required
mission essential capability.
EXAMPLES:
• Problems affects non-mission critical functions
• Operational procedure with workload impact that should be automated
• Impact of problem is minimal

• Correctable by contractor workaround*
Beta/User Acceptance Testing:
The problem is a test inconvenience or annoyance, which does not affect a required mission
essential or test capability. If moved into the production environment before correcting, an
acceptable workaround could be instituted to prevent the inconvenience. **
EXAMPLES:
• 	Problem affects non-mission critical functions
• 	Operational procedure with workload impact that should be automated
• 	Impact of problem is minimal
• 	Correctable by contractor workaround*
Priority 5 Classification
Production:
All other documented system problems. These could include operator errors, an inability to
reproduce the reported problem, a problem with insufficient information, or documentation
errors. The system maintainer should request approval from the (GTL) before coding and
implementing any system enhancements.
EXAMPLES:
• 	A/B and DME MACs requested enhancements
• 	Documentation errors
• 	Problem affects non-mission critical functions
• 	Minimal impact
Beta/User Acceptance Testing:
All other documented system test problems. These could include operator errors, an
inability to reproduce the reported problem, a problem with insufficient information, or test
documentation errors. The system maintainer should work to correct these issues as soon
as possible but any system enhancements should be discussed with the GTL.

EXAMPLES:
• Test region or processing enhancements
• Test documentation
• Problem affects non-mission critical test functions
• Minimal impact
* An acceptable workaround is a temporary alternative solution to a confirmed problem in the
shared system that will ensure the contractor is able to accomplish a mission critical capability.
What makes the workaround “acceptable” is it shall be agreeable to both the maintainer and
contractor and does not cause an excessive burden to the contractor. If the maintainer and A/B
and DME MACs cannot come to an agreement on what is “acceptable” the decision will be made
by CMS.
** CMS does not recommend using workarounds in the test region in order to “pass” test cases.
The institution of a workaround should be used in order to implement a CMS mandate where the
system maintainer may not have time to adequately code a fix before the software is delivered
for production installation.
40.2.1 - Implementing Validated Workarounds for Shared System Claims
Processing by All Medicare DME MACs
(Rev. 97, Issued: 01-15-16, Effective: 09-21-15, Implementation: 09-21-15)
Medicare A/B, DME contractors shall implement workarounds within the shared systems for
problems when formally defined as a Priority 3 or Priority 4 without obtaining written
permission from a Project Officer or Regional Office.
Shared system problems that are formally defined as a Priority 3 or a Priority 4 have acceptable
workarounds which provide temporarily alternative solutions. In order for a A/B/DME MACs to
implement a workaround, the shared system maintainer must first validate the problem, confirm
that the workaround exists, is systematically viable and does not cause adverse effects. The
implementation of such workarounds will eliminate delay in adjudication of Medicare claims and
the payment to providers. Utilizing a Priority 3 or Priority 4 workaround shall not diminish the
integrity of the shared systems and shall not include such actions as deactivating standard edits.
The shared system’s priorities are formally defined at Section 40.2 of this chapter.
40.3 - Shared System Testing Requirements for Shared System Maintainers,
Single Testing Contractor (STC)/Beta Testers, and Medicare A/B, Durable
Medical Equipment (DME) Administrative Contractors
(Rev. 97, Issued: 01-15-16, Effective: 09-21-15, Implementation: 09-21-15)
Medicare requires implementation of a limited number of shared systems that must be used by
all MACs for the administrative responsibilities of Traditional Medicare (Part A, B and DME

claims). This eliminates the need for each A/B, DME MAC to repeat development of the base
system as part of the complete system development life cycle (SDLC).
CMS requires that the shared system quarterly release be subjected to the complete testing life
cycle prior to production release. The goal is to ensure that all changes function as intended and
that the implementation of changes does not degrade or otherwise unintentionally affect existing
system capability and function prior to implementation. This requires that the shared system be
subjected to all levels and types of testing including unit testing, integration testing, systems
testing, functional testing, interface testing, performance testing, regression testing, and
operational testing. Definitions are provided in subsection 40.3.9.
The Shared System Maintainer and the Medicare A/B, DME MACs each have specific roles in
testing the shared system quarterly release. Additionally, CMS contracts with a CMS Single
Testing Contractor (STC) to act as a Beta tester for the FISS, MCS, VMS, and CWF shared
systems respectively.
The CMS Single Testing Contractor (STC) assumes primary responsibility for testing the
Medicare Shared Systems. The STC will be fully responsible for meeting the requirements of
the Beta tester as outlined in Chapter 7, Section 40.3, including all subsections. STC interface
testing with HIGLAS will be initiated as a shadow test on Part A. The STC shall also initiate
Railroad Retirement Board (RRB) testing. Three Medicare Contractor numbers have been
established to accommodate STC testing. They are 00888 for MCS systems testing, 00388 for
FISS systems testing, and 44410 for DMEMAC systems testing.
This section identifies the testing responsibilities for each organization to ensure that each shared
system quarterly release satisfies all CMS requirements. All organizations shall have processes
in place to meet these requirements. Testing activities will generally begin 3 to 4 months in
advance of the release date, particularly for shared system maintainers.
40.3.1 – Shared System Testing Requirements for Shared System Maintainers,
Single Testing Contractor (STC), and DME MACs
(Rev. 97, Issued: 01-15-16, Effective: 09-21-15, Implementation: 09-21-15)
Review subsection 40.3.9, Definitions, for a description of key testing terminology.
1. 	Maintainers of a Shared System shall plan and execute all the essential levels of testing. At a
minimum this includes Unit testing, Integration testing, System testing, and Regression
testing. Shared System Maintainers are also responsible for performing Interface Testing.
2. 	Beta testers may initiate testing at the integration level, but are primarily dedicated to testing
at the system level, including regression testing. Beta testers are also responsible for
performing Interface Testing, which includes full data exchanges between the shared system
maintainers, and other systems.
3. 	Shared System Maintainers and Beta testers shall maintain a test environment that enables
system-testing activities to replicate the production environment, as closely as required to
effectively test. CMS provided all Beta testers with a date simulation tool to facilitate executing
test cases with future dates (e.g., service dates, admission dates) without turning off edits or
altering effective dates in the test environment.

40.3.2 – Minimum Testing Standards for Shared System Maintainers and the
Single Testing Contractor (STC)/Beta Testers
(Rev. 97, Issued: 01-15-16, Effective: 09-21-15, Implementation: 09-21-15)
1. 	The Shared System Maintainers (SSMs), and the Single Testing Contractor (STC) shall fully
test the quarterly release to ensure it is ready to be elevated to production. For the quarterly
release to be considered fully tested, all the requirements contained within the release must
be tested. Shared System Maintainers (SSMs) and the Single Testing Contractor (STC) must
be able to demonstrate the degree to which each discrete requirement within a CR has been
tested and by which test cases. It is therefore mandatory that the testers maintain traceability
between test cases and the discrete requirements being implemented in the release.
Additionally, for each CR or transmittal under test, the Shared System Maintainers and the
Single Testing Contractor (STC) must ensure that each discrete requirement specified in the
Business Requirements section of any CR/transmittal has been fully tested. 	The Shared
System Maintainers and the Single Testing Contractor (STC) shall specifically:
• 	Maintain a repository of test requirements against which all test cases must be traced.
• 	Prepare and execute a set of test cases that demonstrate the requirements were correctly
implemented for all change requests within the quarterly release.
• 	Maintain traceability between each test case and the requirement that the case was
designed to test.
2. 	The Shared System Maintainers and Single Testing Contractor (STC) shall distinguish each
test requirement with a unique Requirement Identifier. The Requirement Identifier must be a
number or qualifier preceded by the CMS CR number and SSM CR number, separated by
dashes. The format of the Requirement Identifier is: [SSM CR No.]-[CMS CR No.]-
[Requirement No.], where:
• 	SSM CR No. – is a number that identifies a CMS mandate or user change request under
test. Free form text can also be used to identify changes not associated with maintainer
CR numbers, e.g., “Regression” to indicate regression testing. Avoid spaces and use
underscore symbol “_” instead. Dashes not allowed within this number; they are
reserved for separation between the individual numbers in the Requirement Identifier.
• 	CMS CR No. – is a minimum 4-digit number that identifies the CMS CR associated with
the maintainer CR number. If no CMS CR is associated with a maintainer CR, use
“0000”. Dashes are not allowed. Avoid spaces and use underscore symbol “_” instead.
Dashes not allowed within this number; they are reserved for separation between the
individual numbers in the Requirement Identifier.
• 	Requirement No. – is a number that uniquely identifies the requirement with the CR. For
any requirement taken from the Business Requirements section of a CMS CR, use the
actual number from the Requirement # column. Do not repeat the CMS CR number.
Dashes not allowed within this number; they are reserved for separation between the
individual numbers in the Requirement Identifier.

Example: Maintainer CR 22522 corresponds to CMS CR 2634. Business Requirement
2.8 was taken directly from CMS CR 2634. The Requirement Identifier would be 22522-
2634-2.8.
3. 	The Shared System Maintainer and the Single Testing Contractor (STC) shall complete Test
Case specifications that include specific input situations and the expected results associated
with a single test purpose. Each test case specification must include the following:
• 	A unique Test Case Identifier (which includes a cross-reference to the requirement in
which the case is designed to test);
• 	The specific objective or purpose of the case;
• 	Input specifications (i.e., a description of the input situation[s]);
• 	Output specifications (i.e., a description of the expected results); and
• 	Intercase dependencies - in instances where the test results of one test case may impact
other test cases, the test case specification must identify the other test case(s) and
describe the relationship(s).
Refer to section 40.3.10, Test Case Specification Standard, for the specific format required to
electronically maintain test cases.
4. 	All Test Cases must contain a unique Test Case Identifier. The CMS standard for the Test
Case Identifier is the Requirement Identifier, followed by a number that uniquely qualifies
the test case specification, separated by a dash.
The format of the Test Case Identifier is: [Requirement Identifier]-[Test Case Number],
where:
• 	Requirement Identifier – is the actual identifier of the requirement being testing by the
case.
• 	Test Case Number – is a number that uniquely qualifies the test case. This is generally a
sequential number. This is necessary since more than one test case is often needed to test
a single requirement. 	Dashes not allowed within this number; they are reserved for
separation between the individual numbers in the Test Case Identifier.
Example: Two test cases were developed to test the implementation of Requirement
22522-2634-2.8 (see example above). The unique Test Case Identifier for the two test
cases would be 22522-2634-2.8-01 and 22522-2634-2.8-02.
5. 	The Shared System Maintainers and the Single Testing Contractor (STC) shall document and
execute both positive and negative test cases to ensure the requirements of the release are
correctly implemented.
• 	Positive test cases are required to ensure that the system is directly fulfilling the
requirements as specified. One or more positive test cases are required for each

requirement. As an example, if a program mandate effects a change for services
beginning on July 1, a positive test case would include service dates in July or later and
validate that the actual mandate was correctly implemented.
• 	Negative test cases test cases are required to ensure that the system does not perform an
incorrect action. As an example, if a program mandate effects a change for services
beginning on July 1, a negative test case would ensure that implementing the mandate did
not negatively impact claims with service dates prior to July 1. Unlike positive test cases,
a negative test case may not be applicable to every requirement within a CR.
Additionally, although due diligence might necessitate a negative test case, the need may
be mitigated by an existing case in your regression test set.
6. 	The Shared System Maintainers and the Single Testing Contractor (STC) shall document all
test cases and the actual results for each test case electronically. Each test case and the
associated results must be stored in a test management repository (i.e., Application Lifecycle
Management (ALM) tool) and must at a minimum contain the data elements outlined in the
CMS Test Case specification standard. See subsection 40.3.10 for the Test Case
specification standard.
7. 	The Shared System Maintainers and the Single Testing Contractor (STC) shall maintain a
test log that provides a record of each test execution. Test Log requirements may be fulfilled
by correctly using the ALM “run” feature (or an equivalent tool or approach) as outlined in
the Quarterly Release Test Management User Guide.
8. 	The Shared System Maintainers and the Single Testing Contractor (STC) shall execute a full
regression test set on their system for every quarterly release. Each testing entity shall
perform regression testing within their designated testing window as outlined in subsection
40.3.7, Timeframe Requirements.
9. 	The Shared System Maintainers and the Single Testing Contractor (STC) shall perform
interface testing.
• 	The Shared System Maintainers and the Single Testing Contractor (STC) shall validate
that all output files are correctly created by their system. The SSMs and STC shall
validate that their system can accept and correctly process all input files.
• 	The Shared System Maintainers and the Single Testing Contractor (STC) shall perform
interface testing that includes full data exchanges (both ways) between the shared system
and any principal claims processing adjudication or financial system (e.g., the CWF and
HIGLAS respectively). The STC is required to perform data exchanges with HIGLAS
after HIGLAS is implemented at the STC’s data center.
• 	The Shared System Maintainers and the Single Testing Contractor (STC) shall complete
an integrated system test coordinating the maintenance of test data baselines, such as
beneficiary data, with the CWF Beta tester.
40.3.3 – Testing Standards Applicable to all Beta Testers
(Rev. 97, Issued: 01-15-16, Effective: 09-21-15, Implementation: 09-21-15)

1. 	Each shared system maintainer and each beta tester shall complete integrated testing with the
CWF Beta tester, using coordinated beneficiary data, in the execution of their test cases. All
test cases involving CWF functionality (related to claims adjudication) must be executed in
an integrated test with the CWF. This requires full data exchanges between testing entities
including:
• 	Satellite files being sent from the shared systems to the CWF Beta tester; and
• 	Response files being sent from the CWF to the shared system Beta testers.
2. 	Each Beta tester shall:
• 	Utilize the standard CMS Test Management tool and repository to documents all test
cases and results.
• 	Follow the procedures outlined in the Quarterly Release Test Management User Guide in
order to complete the documentation of test runs and results.
3. 	Each STC/beta tester shall review all Shared System Maintainer release documentation for
completeness, accuracy, and usability. Any questions, problems, or issues with the
documentation shall be forwarded to both the Shared System Maintainer and CMS.
4. 	Each STC/beta tester shall conduct performance testing to reasonably assure that the system
provides acceptable response times, throughput rates, and processing windows and can
accommodate production workloads.
5. 	The CMS testing requirements outlined in section 40.3 may require the STC/beta tester to
test a specific type of bill, specialty, or claim situation for which they do not possess the
required level of expertise. In these instances, the STC/beta tester must partner with a
Medicare A/B, DME MAC that possesses both the expertise and capabilities to test the
specialty or claim type. As an example, should the STC/beta tester not have the operational
capability or expertise to process Home Health claims, they are expected to partner with an
A/B MAC (HHH) to complete the required HHA testing. Ultimately, the STC/beta tester is
responsible for ensuring all test cases are exercised. Any partnerships that are established to
complete the testing requirements shall be arranged and managed by the STC/beta tester.
40.3.4 - Testing Requirements Applicable to the CWF Beta Tester
(Rev. 43; Issued: 03-30-07; Effective: 07-01-07; Implementation: 07-02-07)
The CWF Beta tester shall act as a test host and exchange data with entities testing the FISS,
MCS, and VMS shared systems. The testing entities include all shared system maintainers and
the shared system Beta testers.
40.3.5 – Part A/Part B (A/B) Durable Medical Equipment (DME) Medicare
Administrative Contractor (MAC) (User) and the Single Testing Contractor
(STC) Testing Requirements
(Rev. 97, Issued: 01-15-16, Effective: 09-21-15, Implementation: 09-21-15)

A/B, DME MACs are not mandated to prepare and execute test cases that cover Medicare
business requirements implemented within the base system in standard system and CWF
quarterly releases. Shared System Maintainers and the STC are fully responsible for testing the
base functionality. The A/B, DME MAC (users) shall test their local/unique components and
conduct a limited, end-to-end, operational test.
1. 	A/B, DME MACs shall fully test their local components and processing rules prior to
production implementation of the quarterly release. This testing is applicable for all local
components and processing rules modified since the previous quarterly release.
A. A/B, DME MACs shall test any system components they maintain and implement to
support claims processing in addition to the base system. This includes front-end and
back-end components such as those for EDI entry and translation, EDI outbound
processing, and printing (e.g., MSN generation).
B. A/B, DME MACs shall test changes they make to user control files, facilities, and tables
in order to implement new Medicare policy or business rules. Examples of these
facilities include but are not limited to auto adjudication facilities (e.g., ECPS and MCS
SCF) and the MCS SPITAB.
C. A/B, DME MAC shall fully test any shared system functionality that was:
- 	Developed by the shared system maintainer solely for them, or
- 	Developed by the shared system maintainer under a special project in which they
were the exclusive participant.
An example would be a MAC working with CMS on a special demonstration project. In
this example the MAC shall fully test the shared system functionality that was
implemented for the demonstration project.
2. 	A/B, DME MACs shall complete a limited end-to-end operational test that incorporates the
shared system release, integrated with their other claims processing components. These
components include the front-end for claims receipt, translators, the CWF, the financials, and
back-end EDI and report generation. The test must ensure that processing is contiguous from
claims entry, to claims adjudication, and ultimately remittance and Medicare Summary
Notice generation. Through contiguous processing, the interfaces between all key claims
processing components must be exercised. The banking system interfaces such as National
Clearing House (NCH) transfers need not be exercised. The test is limited in the number of
test cases that are required, since shared system maintainers and the STC are testing the base
functionality of the shared system.
A. A/B, DME MACs shall ensure that the integrated systems software can complete cycles
without system abends and produce the expected output. The A/B, DME Medicare
Contractor shall ensure their operational test:
• 	Exercises all claims entry points not fully incorporated in the base system such as
paper and EMC front-end components;
• 	Includes all allowable standard electronic formats and versions;

• 	Includes a variety of claims types; and
• 	Includes all components that support their claims workload and interfaces to the
shared system.
B. The operational test shall include the most recent shared system release received prior to
the initiation of the test. A/B, DME MACs shall initiate the test as required to ensure its
completion and the reporting of any problem prior to production implementation.
3. 	CMS strongly encourages the shared system user community to promote:
• 	Standardizing their system nationally,
• 	Centralizing any table maintenance that implements national Medicare policy at the
system maintainer level, and
• 	Minimizing local variations.
4. 	A/B, DME MACs may perform additional testing on the shared system or duplicate Beta
testing tasks as time permits. At the discretion of their Regional Offices, the A/B, DME
MACs may be required to separately document any testing they perform in addition to their
mandated testing.
5. 	A/B, DME MACs shall test any business rule or event with future dates that they code or set-
up in their Auto Adjudication Software (AAS), prior to implementing the rule or event into
production. Examples of AAS include but are not limited to ECPS, SCF, the Shack, and the
Mill.
a. 	A/B MACS shall submit their date simulation recommendations to the FISS FWG in
advance and participate in discussions at the FWG calls, as required to reach
consensus on a date simulation schedule.
b. 	A/B MACS shall submit their date simulation recommendations to the MCS FWG in
advance and participate in discussions at the FWG calls, as required to reach
consensus on a date simulation schedule.
c. 	DME MACS shall submit their date simulation recommendations to the DMOP TAG
or the CFMTAG in advance and participate in discussions at the TAG calls, as
required to reach consensus on a date simulation schedule.
d. 	The FISS FWG, MCS FWG, and DMOP/CFM TAG shall use the “system date
request process” to provide the VDC(s) their latest “run-date simulation” schedule for
their FISS, MCS, and VMS UAT environments.
e. 	The FWG or DMOP TAG shall maintain their “run-date simulation” schedule for a
minimum of 14 calendars days in advance. Here is an example of a “run-date
simulation” schedule:

Calendar
Date
System
Run Date
Calendar
Date
System Run
Date
Calendar
Date System Run Date
10/8/2015 	10/5/2015 	10/17/2015 	10/14/2015 	10/26/2015 	10/23/2015
10/9/2015 	10/6/2015 	10/18/2015 	10/15/2015 	10/27/2015 	10/24/2015
10/10/2015 	10/7/2015 	10/19/2015 	10/16/2015 	10/28/2015 	10/25/2015
10/11/2015 	10/8/2015 	10/20/2015 	10/17/2015 	10/29/2015 	10/26/2015
10/12/2015 	10/9/2015 	10/21/2015 	10/18/2015 	10/30/2015 	10/27/2015
10/13/2015 	10/10/2015 	10/22/2015 	10/19/2015 	10/31/2015 	10/28/2015
10/14/2015 	10/11/2015 	10/23/2015 	10/20/2015 	10/1/2015 	10/29/2015
10/15/2015 	10/12/2015 	10/24/2015 	10/21/2015 	10/2/2015 	10/30/2015
10/16/2015 	10/13/2015 	10/25/2015 	10/22/2015 	10/3/2015 	10/1/2015
f. 	The FISS FWG, MCS FWG, and DMOP/CFM TAG shall provide a copy of their
“run-date simulation” schedule to their CWF test host.
g. 	The FISS FWG and MCS FWG shall provide a copy of their “run-date simulation”
schedule to the HIGLAS test site as required to accommodate their HIGLAS enabled
contractors.
40.3.6 - Testing Requirements Applicable to all CWF Data Centers (Hosts)
(Rev. 97, Issued: 01-15-16, Effective: 09-21-15, Implementation: 09-21-15)
Each CWF data center or CWF sector host shall:
• 	Forward all satellite software and documentation to the satellites (contractors) to which
they serve as the primary production host;
• 	Install the CWF quarterly release software in a designated test region;
• 	Make the designated test region available their satellites (users) for testing;
• 	Coordinate test data, such as beneficiary data, with the user testers;
• 	Process all satellite files submitted by the users and return all corresponding reply files
generated for users;
• 	Report release problems to the CWF Maintainer and CMS;
• 	Verify with CMS that each of its satellites submitted at least one test file during user
testing; and
• 	The CWF Host shall support future date testing by the MACs.

• 	The CWF Host shall review date simulation schedule submitted by the FISS FWG, MCS
FWG, and DMOP TAG.
40.3.7 - Timeframe Requirements for all Testing Entities
(Rev. 97, Issued: 01-15-16, Effective: 09-21-15, Implementation: 09-21-15)
The SSMs, STC, and MAC shall operate under the testing timeframes shown below for each
quarterly release:
Timeframe Requirements for Testing Entities
1. 	The Medicare A/B, DME MAC or User testing period shall begin four weeks prior to
production implementation.
2. 	The Beta testing period shall begin eight weeks prior to production implementation. The
CWF and standard system Beta testers shall have an exclusive four-week testing timeframe
prior to the initiation of user testing.
• 	The Beta tester shall complete a functional System Test and Regression Test before the
shared system is released to the User community.
• 	Beta testing must also continue through the User testing period. The Beta tester may
initiate performance testing during the user testing period.
3. 	Exclusive CWFM and SSM testing shall continue until Beta testing is initiated eight weeks
prior to production implementation. The SSM and CWFM shall complete a Unit Test (on all
components), Integration Test, System Test, and Regression Test prior to distributing the
shared system release to the designated Beta tester. For all integration, system, and
regression testing, the SSM shall use the most recent version of any third party or CMS
provided software components (e.g., Pricer, OCE, MCE, Grouper) they are provided. The

SSM shall continue testing beyond the exclusive maintainer-testing window due to the late
receipt of some third party or CMS provided software components such as the Pricers and
OCE.
40.3.8 - Testing Documentation Requirements
(Rev. 97, Issued: 01-15-16, Effective: 09-21-15, Implementation: 09-21-15)
1. 	The SSM, STC, and MAC shall maintain documentation that fully demonstrates the
requirements of this transmittal were met for each quarterly release. At a minimum the SSM,
Beta tester, and MAC shall maintain the following test documentation to demonstrate full
compliance:
• 	Test Requirement and Test Case repository with traceability;
• 	Test Log;
• 	Test Status for the execution (run) of each test case (i.e., Pass, Fail, Not Run);
• 	Actual Results for the run of each test case in which the actual results did not match the
expected results; and
• 	Documented proof of each test run, i.e., screen shots, scheduler job logs, etc.
2. 	The SSM, STC, and MAC shall:
• 	Maintain all test documentation for the four quarterly releases prior to the current release
under test. The documentation must be available for review by CMS (or its agent).
• 	Document all software defects (problems) within the CMS specified repository such as
INFOMAN.
3. 	The SSM shall communicate all confirmed software defects (problems) and fixes directly to
CMS in writing through their CMS Maintenance Lead/(GTL) or other designee as specified
by the CMS Project Officer.
4. 	A/B, DME MACs shall provide any testing documentation to their CMS regional office upon
request.
Additional requirements for selected shared system maintainers, STC, and CWF hosts may be
contained in these organizations' individual contracts. Electronic screen shots may be
incorporated/attached into the results of ALM has proof of online results. Test Log requirements
may be fulfilled by correctly using the ALM “run” feature as outlined in the Quarterly Release
Test Management User Guide.
40.3.9 - Definitions
(Rev. 105, Issued: 06-02-17, Effective: 07-03-17, Implementation: 07-03-17)
These definitions are provided to ensure common understanding.

Base Shared System - The FISS, MCS, VMS, or CWF system, which is routinely released by the
Shared System Maintainers to their respective user community prior to any user customization.
This includes all components released by the Shared System Maintainer, including but not
limited to the claim adjudication subsystem, the financial subsystems, and other integrated
components (i.e., Pricer, OCE, MCE, Grouper).
Functional Testing – Testing to ensure that the functional requirements have been met.
Functional testing is performed by the SSMs and the STC.
Integration Testing – Testing combinations of interacting software components that make up
parts of a system. Integration testing is performed by the SSMs, and the STC.
Interface Testing – Testing conducted to evaluate whether subsystems or systems pass data.
Interface testing is performed by the STC.
Local Components – A Local Component as referenced in section 40.3 is any component or
module that supports Medicare claims processing, but is not part of the Base System and is under
the control and maintenance of the MAC.
Maintainer – The Maintainer is an entity to which CMS directly contracts to maintain a Medicare
claim processing shared system (FISS, MCS, VMS, or the Common Working File (CWF)
system). The Maintainer, as referenced in section 40.3, does not refer to an entity to which a
A/B or DME MAC subcontracts to operate their data center or perform other claim processing
support activities.
Operational Testing – Testing conducted to evaluate a system in its operational environment.
Testing to ensure that the aggregate operational systems and their interfaces can be operated
securely with the instructions provided. Operational Testing is performed by the SSMs and the
A/B and DME MACs.
Performance Testing – Testing that applies heavy transaction and processing loads to the system
to ensure that response times, throughput rates, and processing windows remain acceptable and
can accommodate production workloads. Performance Testing is performed by the STC.
Regression Testing – Testing conducted on a system or components to verify that modifications
have not caused unintended effects and that the system or components still complies with its
requirements. Regression testing is performed by the SSMs and the STC.
Regression Test Set – A set of selectable test cases designed to exercise a system over its
functional capabilities and assure that it still works properly after changes have been applied.
Requirement Identifier – A unique number assigned to each requirement comprised of the
Shared System Maintainer CR Number, the CMS CR Number, and an alphanumeric element to
uniquely qualify each requirement. For testing purposes CMS requires that each Test Case
Identifier incorporate the Requirement Identifier to which it is traced.
Stress Testing – Testing that applies a steadily increasing load to the system until it reaches the
point where performance degrades to unacceptable levels.
System Testing – Testing to discover any incorrect implementation of the requirements or
incompatibilities in the software/hardware environment. System testing includes functional

testing, performance testing, and operational testing. System testing is performed by the SSMs
and the STC.
Test Case Specification – A description of an input situation and of the required results
associated with a specific test objective or purpose.
Test Case Identifier – A unique identifier assigned to each test case.
Test Log – A chronological record of relevant detail about the execution of tests. Relevant
details include run date, run time, test status, and actual results.
Test Requirement - A specific requirement that is under test and to which one or more test cases
are traced. Test requirements may be derived from various types of requirements i.e., business
functional requirements, performance requirements etc. Note: Any well-written requirement that
is “testable” may be considered a Test Requirement. Any requirement contained in the Business
Requirements section of a CR or transmittal, also constitutes a test requirement.
Test Set – A collection of test cases that have a common usage.
Unit Testing – The testing of individual units (i.e., software components, modules) or groups of
related units. It is the lowest level of testing and is usually performed by programmers. Unit
testing may be both functional (requirements oriented) and structural (i.e. logic oriented, code
coverage oriented). Unit testing is performed by the SSMs.
40.3.10 - Test Case Specification Standard
(Rev. 97, Issued: 01-15-16, Effective: 09-21-15, Implementation: 09-21-15)
Purpose: 	This standard establishes a controlled outline for the contents and presentation of
a Test Case Specification used by the shared system maintainers and the STC.
Applicability: This standard is applicable to all Test Case Specifications developed by the shared
system maintainers and the STC.
Data Element 	Description
Allowable Values or
Format
Comments
Test Case
Specification
Identifier
Multi-part indicator that
uniquely identifies the test
case specification.
See Test Case
Specification Identifier
Standard.
Test Purpose 	A free form field that
captures the intent of the test
and identifies any key
components of the test, e.g.,
specific codes.
See attached example.

Input
Specification
A free form field that
captures critical information
used to exercise the system
functionality. Information
could be grouped into the
following topics:
Claim Data Requirements
Claims History
Beneficiary Information
Provider Information
See attached example.
Intercase
Dependencies
(Predecessor
Transaction
Identifier)
The test case specification
identifier of the transaction
that must be entered into and
processed by the system prior
to processing the transaction
described by the test case
specification.
See Test Case
Specification Identifier
Standard.
Output
Specification
A free form declarative
statement that identifies the
expected results from
performing all the steps, as a
collection, within the test.
Test Type 	A one-character indicator to
identify whether the test is
positive or negative.
P = Positive Test
N = Negative Test ALM
Plan Tab
(Required
User Defined
Fields)
Originator 	A one-character indicator to
identify the originating entity
(designer) of the test case.
B = Beta
C = CMS/QRTM
M = Maintainer
Test Status 	Summary indicator for a test
case.
PS = Passed
FA= Failed
NR = Not Run
IN = Incomplete
ID = Invalid Data
IC = Invalid Case
Required
Test
Execution
(Run)
Elements
Test Results 	Free form declarative
statement of actual results for
a test case when the actual
results do not match the
expected results.
Optional Information: Industry best practices demonstrate that additional granularity may be
necessary to document discrete key test actions that should be executed and documented. These
items are referred to as test steps. A test case specification may have one or more test steps.
When documenting test steps, the following standard applies:

Step Number 	Unique identifier for each test
step.
“Step n”
Where “n” is a sequential
counter for each step
starting at 1.
There is at least one test
step in each test case
specification, but usually
contains multiple test steps.
Optional
Test
Case
Elements	Step
Description
A free form declarative
statement that identifies the
action taken to perform the
test. The step description
statement usually begins with
a verb.
Expected Step
Results
A free form declarative
statement that identifies the
expected results from
performing the associated
step description.
Example #1
Test Case Identifier 	4419-2825-5.2-001
Test Purpose
To confirm that the A/B MAC (A) claims processing systems
accept, process, and assign reason code 30 (Payment adjusted
because the patient has not met the required eligibility, spend down,
waiting or residency requirements) to Inpatient Hospital claims
submitted on Type of bill (TOB) 111 (Hospital Inpatient Part A;
admit through discharge) with Dates of Service (DOS) on
01/01/2004 when a beneficiary is not lawfully present in the United
States.
Input
Specification
 Claims History 	None
Beneficiary
Information
Beneficiary must be unlawfully present in United States.
Beneficiary elected English as primary language
Provider Information 	Provider Number Range = XX0001-XX0999
Claim Data
Requirements
TOB = 111
DOS = 01/01/2004
Intercase
Dependencies None
Output Specification
Claim will be assigned reason code 30 indicating beneficiary is not
lawfully present in the United States, generating MSN message 5.7
(Medicare payment may not be made for the item or service because
on the date of service, you were not lawfully present in the United
States).
Test Type 	P
Originator 	C
Test Status 	PS
Test Results 	Claim was assigned appropriate reason code

40.3.11 - Single Testing Contractor (STC) Non-Testable Conditions and
Potential Testing Impacts
(Rev. 125; Issued: 07-05-19, Effective: 08-05-19, Implementation: 08-05-19)

ID 	LOB 	STC Not Testable Conditions and Potential Testing Impacts
1
FISS,
MCS,
VMS
Electronic Correspondence Referral System functionality (ECRS) - The STC
does not interface with ECRS.
2
FISS,
MCS,
VMS
Recovery Audit Contractor (RAC) and/or Recovery Audit Contractor Data
Warehouse (RACDW) - The STC does not interface with the RAC or the
RACDW. The STC does have the ability to test RAC related changes in the
shared system applications.
3
FISS,
MCS,
VMS
Non-Base Job System Processing. The STC does not test non-base jobs.
4 	FISS 	ECPS events – The STC does not test MAC controlled ECPS events.
5 	VMS 	Super Op events - The STC does not test MAC controlled Super Op events.
6 	MCS 	SCF Logic - The STC does not test MAC controlled SCF Logic.
7
FISS,
MCS,
VMS
Local Coverage Determinations (LCDs) - The STC does not test MAC LCD or
medical policy. 	MACs conduct LCD and medical policy testing.
8 	MCS
Interactive Voice Response (IVR) - STC would not do end-to-end testing of
MCS base system changes for the IVR. The STC does have the ability to test
IVR related changes in the shared system.
9 	MCS
Automated Response Unit (ARU) - STC would not do end-to-end testing of
MCS base system changes for the ARU. The STC does have the ability to test
ARU related changes in the shared system.
10
FISS,
MCS,
VMS
Optical Character Recognition (OCR) - The STC does not test changes to OCR
functionality.
11
FISS,
MCS,
VMS,
CWF
Contractor ID specific logic – The STC is unable to conduct state or jurisdiction
specific testing that requires a specific contractor number for processing.
12
FISS,
MCS,
VMS
Printing – The STC does not have a print vendor and does not test backend
print/mail functions.

13
FISS,
MCS,
VMS,
CWF
Testing that requires large volumes of data – The STC environment contains a
limited number of claims. Thus, the STC may not be able to identify volume-
related issues in its test environment.
14
FISS,
MCS,
VMS,
CWF
Runbooks are documentation artifacts maintained by the SSMs that provide
instructions regarding how jobs are to be scheduled (daily, weekly, monthly, on
request etc.) and predecessor/successor relationships for jobs that must precede
or succeed, as well as containing comments on known abend return codes the
job is programmed to return sometimes including instructions on how to
rerun/restart each abend return code. As Runbooks are documentation in
nature the STC does not test Runbooks.
15 	CWF 	Enrollment Database (EDB) - The STC does not interface with the EDB system.
16
FISS,
MCS,
VMS,
CWF
Processes that are designed to only work in a test environment - Processes that
are designed to only work in a test environment and will never be promoted or
utilized in the production environments. This includes the internal testing
facility (ITF), the CWF response generator, the HIGLAS response generator,
and the MBI generator.
17
FISS,
MCS,
VMS
Healthcare Integrated General Ledger Accounting System (HIGLAS) - The
STC is not responsible for testing HIGLAS changes. The shared systems will
continue to test HIGLAS.
18 	FISS INFOMAN - The STC does not test CRs implemented by the FISS SSM that
update the release identifier on the main CICS screen in the FISS application.
19
FISS,
MCS,
VMS,
Electronic Funds Transfer (EFT) - The STC does not conduct testing with
financial institutions, and is therefore unable to test the EFT transactions. The
STC inspects the EFT files created from the shared systems and processes them.
20 FISS,
MCS
Payment File Development Contractor (PFDC) - The STC does not interface
with the PFDC system. Changes to the file are tested by the STC by manually
sending and receiving a file. The STC inspects the files created from the shared
systems and processes them.
21
FISS,
MCS,
VMS,
CWF
Integrated Data Repository (IDR) - The STC can test IDR file changes as part
of the shared system, but the files are not automatically sent to the IDR
contractor. STC manually sends files to the IDR contractor twice during the

release. The STC inspects the files for accuracy created from the shared systems
and processes them.
22 	FISS
Quality Improvement Evaluation System (QIES) - The STC does not interface
with QIES. The STC inspects the files for accuracy created from the shared
systems and processes them.
23
FISS,
MCS,
VMS,
CWF
Provider Statistical and Reimbursement System (PS&R) - The STC does not
interface with the PS&R system. The STC inspects the files for accuracy
created from the shared systems and processes them.
24
FISS,
MCS,
VMS,
CWF
Production Performance Monitoring System (PULSE) - The STC does not
interface with PULSE. The STC inspects the files for accuracy created from the
shared systems and processes them.
25 	MCS
Provider Enrollment System (PES) - The STC does not have the PES
application that is used exclusively by the Railroad Retirement Board Specialty
MAC. The STC is unable to test the PES application.
26
FISS,
MCS,
VMS
Provider Enrollment Chain and Ownership (PECOS) - The STC does not utilize
the PECOS system to generate enrollments. STC manually creates a file when
needed for testing.
27
FISS,
MCS,
VMS
Electronic Submission of Medical Documentation (esMD) - The STC does not
have connectivity with esMD. The STC does have the ability to test esMD
related changes in the shared system.
28 	CWF
Affordable Care Organization (ACO) – The STC does not have connectivity
with the ACO. The STC does have the ability to test ACO related changes in the
shared system.
29 	CWF
CWF MBI (Medicare Beneficiary ID) XWALK - There are some connectivity
tests that STC cannot execute since the XWALK in STC is set up differently
compared to production. The XWALK in the STC environment is embedded in
the CWF CICS region that houses all other STC CWF data whereas the
XWALK in production is in a separate CICS region called Host K. The STC
does not connect to Host K.

40.3.12 - Next Generation Desktop (NGD) Requirements
(Rev. 105, Issued: 06-02-17, Effective: 07-03-17, Implementation: 07-03-17 )
CMS has fully deployed the Next Generation Desktop (NGD) to the contractors’ beneficiary
customer service contact centers. The NGD is a multiple call center application that is used by
Medicare Customer Service Representatives (CSRs) to answer inquiries and perform operations
on behalf of CMS beneficiaries and the American public.
The NGD is designed to pull customer service-needed information into a common desktop
application. As such, the NGD requires data exchange with CMS shared systems (VMS, CWF,
FISS, MCS) and standard systems (Enrollment Database (EDB)/Master Beneficiary Database
(MBD), Master Beneficiary Record (MBR), Group Health Plan (GHP)/Maricopa Managed Care
System (MMCS). Note: NGD may integrate with additional systems as future releases are
developed.
Because NGD integrates with the shared systems, periodic changes will be made to the NGD
Integration Layer as a result of the shared systems quarterly release process. The NGD
maintainer will be required to update NGD in shares systems quarterly releases (Jan, Apr, July,
Oct.) The NGD maintainer will be required to perform the various activities associated with
changes to the NGD (i.e., unit and system testing). In addition to the shared systems quarterly
release schedule, the NGD will adhere to a separate quarterly functional release process for
NGD-specific updates and defect correction.
The NGD maintainer shall follow all of the requirements identified in Section 40.3 for the shared
system maintainers except as indicated below:
1. Section 40.3.1 Maintainers and Beta Testers –Required Levels of Testing, #3 is not applicable
to NGD Beta testers.
2. Section 40.3.2 (#2) Minimum Testing Standards for Maintainers and Beta Testers, for NGD
naming conventions, the NGD Maintainer should refer to the NGD test Plan.
3. Section 40.3.2 (#4) Minimum Testing Standards for Maintainers and Beta Testers, for NGD
test case identifiers, the NGD maintainer should refer to the NGD System Test Plan.
4. Section 40.3.7 Timeframe Requirements for Testing Entities – NGD testing timeframes are as
follows:
• 	The official NGD User Acceptance testing period conducted by the VCS Support
Contractor shall begin 2 weeks prior to production implementation.
• 	The overall NGD testing period shall begin 3 weeks prior to production
implementation. The NGD VCS Support testers shall have an exclusive 1 week
testing timeframe prior to the initiation of user testing (Validation testing)
-The User Acceptance tester shall complete a functional System Test and Regression Test before
the system is released to the User community.

• Exclusive NGD System Maintainer testing shall continue until User Acceptance
testing is initiated 3 weeks prior to production implementation. The NGD
Maintainer shall complete a Unit Test (on all components), Integration Test,
System Test, and Regression Test prior to distributing the shared system release
to the designated Beta Tester.
5. Section 40.3.8 Testing Documentation Requirements (#2) For NGD, documentation of all
software defects (problems) should be through ClearQuest.
50 - Contractor Implementation of Change Requests and Compliance with
Technical Direction Letters
(Rev. 11395, Issued:05-04-2022, Effective:05-31-22, Implementation:05-31-22)
POLICY
Contractors shall implement all issued Change Requests (CRs) and comply with all issued
Technical Direction Letters (TDLs). Medicare Administrative Contractors (MACs) shall prepare
and transmit the quarterly Contractor Implementation of Change Request (CRIR) and Technical
Direction Letter Compliance Reports (TCR) reports as directed below.
The CRIR shall contain all CRs to be implemented within that fiscal quarter. If CMS omitted a
CR that should have been included in the report, the contractor shall add the CR to the bottom of
the report in red font. MACs are not required to report on or add Shared System Only CRs (i.e.,
no MAC Responsibility checked).
The TCR shall contain all TDLs issued that fiscal quarter, with the exception of contractor-
specific TDLs. TDLs issued to specific contractor(s) shall be added by that contractor at the
bottom of the report in red font. If CMS omitted a TDL that should have been included in the
report, the contractor shall add the TDL to the bottom of the report in red font.
A CMS Central Office (CO) representative will notify the MACs via a TDL (within two weeks
of the end of each fiscal quarter) that the CRIR and TCR reports are available to download on
Electronic Change Information Management Portal (ECHIMP). MACs shall enter all applicable
information into the reports. MACs shall upload the completed reports into the CMS ART
system. MACs shall also then send the completed reports to the CMS CO mailbox at
CR_IMPL_REPORTS@cms.hhs.gov. NOTE: There are no spaces in this email address.
Underscore “_” separates the words CR_IMPL_REPORTS.
The CRIR and TCR reports are due no later than the 28 th of the month in which the reports are
due, as indicated below. If the report due date of the 28th falls on a weekend or a holiday; each
MAC shall submit the report on the next business day following the due date.
• 	Quarter 1 includes October, November, and December. The report for Quarter 1 is
due no later than February 28th.
• 	Quarter 2 includes January, February, and March. The report for Quarter 2 is due
no later than May 28th.

• 	Quarter 3 includes April, May, and June. The report for Quarter 3 is due no later
than August 28th.
• 	Quarter 4 includes July, August, and September. The report for Quarter 4 is due
no later than November 28th.
Each MAC shall complete and submit one CRIR by jurisdiction, one TCR by jurisdiction, cover
Letter/Attestation Statements, and if necessary, a separate explanation document. MACs with
multiple jurisdictions may complete a separate sheet within a single Excel workbook for each
jurisdiction.
In addition, each contractor shall write and maintain written procedures on its change
management process (i.e., Standard Operating Procedures – SOP). Elements should include, but
are not limited to, written procedures for the timely processing of CMS instructions (issued CRs
and TDLs) from the CMS DRI MAILBOX and CMS TDL MAILBOX, written procedures of the
contractor’s CR and TDL distribution process (including, but not limited to, the dissemination of
provider education information), written procedures for CR implementation and TDL
compliance (including written documentation to verify implementation/compliance).
Contractors shall retain the written documentation to verify CR and TDL
implementation/compliance using CMS’s records retention guidelines.
Upon request from CMS, contractors shall supply the written procedures of their change
management process, as well as written documentation to verify CR and TDL
implementation/compliance to CMS.
Implementation Date
I. Definition
Refer to section 50.4.2 of this chapter for the definition of the implementation date.
II. Supporting Information
For any instruction affecting providers, regardless if there are Systems or Non-systems changes,
CMS gives at least 90 days’ advance notice to the providers. That is, CMS must issue the
instruction at least 90 days prior to the implementation date to give providers enough time to
implement the instruction. The vehicle used to alert providers 90 days prior to an instruction’s
implementation date is the CMS Quarterly Provider Update, which can be accessed at:
http://www.cms.hhs.gov/QuarterlyProviderUpdates/01_Overview.asp
There are four exceptions to the 90 days’ advance notice policy: (1) the instruction is contractor
specific and therefore does not affect providers; (2) the instruction is a correction/clarification
where the previously issued instruction contained typos or errors of fact or omissions; (3) the
instruction is a routine or recurring item (which qualifies it to be included on the Mid-Quarter
List in the Provider Update); and (4) the instruction is approved by the CMS Administrator to be
published immediately or by a certain date.

If a previously issued instruction is re-issued with revised MAC requirements and a revised
implementation date is not specified, MACs shall comply with the revised instruction as soon as
possible but no later than 10 business days from the CR’s date of issuance.
For a system change, the Initiator of the CR will specify an implementation date that corresponds
to one of the quarterly release dates. Usually, the quarterly release date will be the first Monday
of the quarter. Non-recurring system changes are usually issued five months in advance of the
implementation date. On occasion, an off-cycle release date can be approved by OSORA and/or
the Administrator. This exception tends to occur most frequently with the implementation of
National Coverage Determinations (NCDs) and corrections to finals.
For a Non-system change that has no impact on providers, the Initiator of the CR may specify the
implementation date as 30 days from issuance. For a Non-system change that has provider
impact, the Initiator of the CR may specify the implementation date as 90 days from issuance.
After the comment period ends and the Initiator of the CR has addressed all comments, he/she
prepares a final CR package for CMS clearance. The last part of the CMS clearance process
involves obtaining approval from the Medicare Change Control Board (MCCB). The MCCB, in
consultation with the Initiator of the CR, will determine the time period needed for implementing
each change request. After the clearance process is completed, the Office of Strategic
Operations and Regulatory Affairs/Issuances & Records Management Group (OSORA/IRMG)
will insert the actual implementation date before issuing the CR as a final instruction.
COMPLETING AND SUBMITTING THE QUARTERLY CR IMPLEMENTATION
REPORT (CRIR)
Medicare Administrative Contractors (MACs) shall complete the CR Implementation Report, as
follows, for each jurisdiction. MACs with multiple jurisdictions may complete a separate sheet
within a single Excel workbook for each jurisdiction.
If CMS omitted a CR that should have been included in the report, the contractor shall add the
CR to the bottom of the report in red font. MACs shall update the report in the same manner as a
CMS CO entered CR, unless specifically instructed below to exclude specific items.
Header Rows
The report contains three header rows.
1. 	Header Row 1, Contains the title, “CR Implementation Report (CRIR) – Quarter X
(MMM-MMM) YYYY,” where X is the number of the quarter, MMM-MMM are the
months included in that quarter, and YYYY is the Calendar Year. This data will be
completed by CMS CO.
2. 	Item 1: Header Row 2, MACs shall enter their Contractor Name and Jurisdiction identifier
in Item 1 of the report.
3. 	Item 2: Header Row 2, MACs shall enter the “Date Report Submitted” to CMS in Item 2 of
the report in MM/DD/YYYY. [This is the date the report is e-mailed to CMS CO.]

4. 	Item 3: Header Row 2, Report Due. This is the date the report is due to CMS CO. This
date will be completed by CMS CO.
5. 	Item 4: Header Row 3, CRIR Contractor Contact (First Name, Last Name, Phone). MACs
shall enter the first name, last name, and phone number of the individual CMS CO should
contact to ask questions regarding information in this report. Contact must be
knowledgeable on the contents of the report.
Details Rows
Below the header Rows, Detail Rows shall be completed as follows:
1. 	Item 5 (No.) - This field contains a consecutive number to track the number of CRs on the
report. CMS CO will complete this field for all CRs included on the report. If the
contractor adds additional CRs, they should continue numbering from the previous CMS
entered row in red font. For example, if CMS included 15 CRs on the report, the contractor
shall begin numbering in this field with 16 in red font.
2. 	Item 6 (CMS CR #) - CMS CO will complete this field with the CMS CR numbers
implemented during the quarter.
3. 	Item 7 (CMS Transmittal #) - CMS CO will not complete this field.
4. 	Item 8 (Subject) - CMS CO will complete this field with the subject for all CMS CRs
implemented during the quarter.
5. 	Item 9 (CMS Published Implementation Date MM/DD/YYYY) - CMS CO will complete
this field with the CMS Published Implementation date in MM/DD/YYYY format for all
CRs implemented during the quarter.
6. 	Item 10 (Applicable Workload? (“X” or blank)) - MACs shall complete this field with an
“X” for all CRs applicable to their workload or leave the field blank if the CR is not
applicable to their workload. The CR is considered applicable to the contractor if any of
the business requirements in the CR were required to be implemented by the contractor in
the reporting period. Note: Shared System Only CRs (with no MAC responsibility
checked) are considered not applicable.
7. 	Item 11 (Completed by Implementation Date? (“Y”, “N”, or blank)) - MACs shall
complete this field with a ‘Y” for all CRs implemented on or before the CMS Published
Implementation Date indicated in Item 9. MACs shall complete this field with an “N” for
all CRs that have not been implemented by the implementation date and MACs must select
a Reason for Delay from Item 12. This field shall remain blank if the CR is not applicable
to the contractor (i.e. Item 10 is blank).
8. 	Item 12 (Reasons for Delay (leave blank if implemented by due date)) - This field shall
remain blank if the CR has been implemented on or before the CMS Published
Implementation date (Item 11 is “Y”) or is not applicable to the contractor workload (i.e.
Item 10 is blank). MACs shall select one of the following Reasons for Delay from the

drop-down list for all applicable CRs not completed by the CMS Published Implementation
date indicated in Item 9 (i.e. Item 10 has an ‘x’ and Item 11 has a “N”):
01. 	Due date changed due to TDL
02. 	Due date changed due to CR
03. 	Retired: MLN delay is retired as a reason for delay
04. 	CMS delay of file transmission
05. 	System related delay
06. 	CR extension approved or pending
07. 	Deadline past quarter end date
08. 	Other
Reason 01 (Due date changed due to TDL) - Applies only in situations where CMS has issued a
TDL which directs contractors to hold claims and/or otherwise delay the work related to that
specific CR.
Reason 02 (Due date changed due to CR) – Applies only in the following situations:
a. 	Correction final changed the CMS Published Implementation date to be different
than the date indicated in Item 9;
b. 	CR was rescinded/replaced with a different CR number that changed the CMS
Published Implementation date to be different than the date indicated in Item 9;
c. 	Correction or Rescinded/Replaced CR changed the due date of specific Business
Requirements.
Reason 03 (CMS MLN Matters® Article Delay) – Retired
Reason 04 (CMS delay of file transmission) - Applies only in situations when the file needed to
complete work indicated in the CR was not available timely (i.e., payment files related to annual
recurring CRs such as the HCPCS, Pricer, and OPPS).
Reason 05 (System related delay) – Applies only in the following situations:
a. 	Shared System Maintainer (SSM) production problem prevents a MAC from
completing a specific task in the CR;
b. 	Non-MAC maintained system (e.g., PECOS, HIGLAS, CWF, etc.) production
problem prevents a MAC from completing a specific task in the CR.
Reason 06 (CR extension approved or pending) - Applies only in situations where CMS
Contracting Officer Representative (COR) has approved an extension of the implementation date
specifically referencing this CR.
Reason 07 (Deadline past quarter end date) - Applies only in the following situations:
a. 	CRs with multiple implementation dates;

b. 	CRs that contain instruction for work to be done after the implementation date
listed in the CR.
Reason 08 (Other) - Applies in all other situations where the implementation of the CR was
delayed, and Reasons for Delay 01 through 07 do not apply.
9. 	Item 13 (Additional Explanation) - MACs shall enter additional comments regarding the
implementation of this CR in this field if a Reason for Delay is selected. Do not update this
field for CRs implemented timely.
For the following Reasons for Delay, MACs shall include the following data:
Reason 01 (Due date changed due to TDL) - TDL reference number (TDL-######) of the
specific TDL which grants an extension and the date to which the extension was granted. Note
the actual implementation date of the CR requirements.
Reason 02 (Due date changed due to CR) - Issued date of the Correction final, CR number and
issued date of replacement CR (if applicable), and the revised implementation date. Note the
actual implementation date of the CR requirements.
Reason 03 (MLN delay) – Retired
Reason 04 (CMS delay of file transmission) - Name of the delayed file, date that the file was
expected, and the date the file was actually received. Note the actual implementation date of the
CR requirements.
Reason 05 (System related delay) – Name of the system, specific production problem
identification number, description of the issue, and resolution date (if applicable). Note the
actual implementation date of the CR requirements.
Reason 06 (CR extension approved or pending) - Name of COR, date approval received, and the
revised due date. Note the actual implementation date of the CR requirements.
Reason 07 (Deadline past quarter end date) - Note impacted business requirement numbers and
the delayed implementation date(s). MACs shall add this CR to the bottom of the CRIR report in
red font for the CRIR report of the quarter where MACs completed their work.
Reason 08 (Other) – Explanation of the delay for situations not applicable to Reasons for Delay
01 through 07. Use the space allowed in Item 13. If additional space is needed, MACs may
submit with the completed CR Implementation report on a separate explanation document.
Provide the following information in a clear and concise manner:
a. Cause of the delay;
b. If not the entire CR, reference the specific delayed Business Requirements;
c. Description of specific tasks that were delayed;
d. Indicate what is the impact to the government and resolution of the issue that
delayed the CR implementation;
e. Note the actual implementation date of the CR requirements.

10. CRIR Totals. This section summarizes the totals for the detail rows.
a. 	Item 14 (Total number of CRs in this report) - This field is calculated. The contractor
shall not update this field. NOTE: This formula sums both CRs added by CMS and
any additional rows of CRs added by the contractor on the spreadsheet.
b. 	Item 15 (Number of CRs applicable to the contractor) – This field is calculated. The
contractor shall not update this field. NOTE: This formula counts CRs that the
contractor has indicated are applicable by marking an “X” in Column F.
c. 	Item 16 (Number of applicable CRs completed by the Implementation Date) - This
field is calculated. The contractor shall not update this field. NOTE: This formula
counts CRs that the contractor has indicated were implemented timely by marking a
“Y” in Column G.
d. 	Item 17 (% of applicable CRs completed by Implementation Date) - This field is
calculated. The contractor shall not update this field. This field reflects the
percentage of applicable CRs completed by the Implementation date, regardless of
CMS or contractor-controlled reasons for delay. NOTE: This formula calculates a
percentage from Item 15 and Item 16.
e. 	Item 18 (% of applicable CRs completed timely) - This field is calculated. The
contractor shall not update this field. This field reflects the percentage of applicable
CRs implemented timely, regardless of contractor-controlled reasons for delay, as
indicated by a selection of Reason for Delay 8 (Other). NOTE: This formula
calculates a percentage from the total number of Reason for Delay 08 indicated in
Item 19 and the total number of CRs applicable to the contractor in Item 15.
11. Each MAC shall complete and submit one CRIR report by jurisdiction, a cover
Letter/Attestation Statement (located on tab 1 of the CRIR Report Template or the Sample
in Section 50.3), and if necessary, a separate explanation document. MACs with multiple
jurisdictions may complete a separate sheet within a single Excel workbook for each
jurisdiction. By the quarterly due date, each MAC shall submit the CRIR report, via e-mail
to the CMS CO mailbox. [The CMS CO mailbox is: CR_IMPL_REPORTS@cms.hhs.gov.
NOTE: There are no spaces in this Web address. Underscore “_” separates the words
CR_IMPL_REPORTS.] If the report due date of the 28 th falls on a weekend or a holiday,
each contractor, including MACs, shall submit the report on the next business day
following the due date.
12. Each MAC shall upload the report to the CMS ART system.
COMPLETING AND SUBMITTING THE QUARTERLY TDL COMPLIANCE
REPORT
Medicare Administrative Contractors (MACs) shall complete the TDL Compliance Report
(TCR) for each jurisdiction as follows. MACs with multiple jurisdictions may complete a
separate sheet within a single Excel workbook for each jurisdiction (name each tab accordingly).

There are some TDLs not issued to all Contractors. If a MAC received a TDL in the reporting
period, the TDL should be included on the report. If CMS omitted a TDL that should have been
included in the report, the contractor shall add the TDL to the bottom of the report in red font.
MACs shall update the report in the same manner as a CMS CO entered TDL, with the exception
of Item 7 (CMS Component). For Contractor added rows, Item 7 may remain blank.
Header Rows
The report contains four header rows.
1. 	Header Row 1, Contains the title, “TDL Compliance Report (TCR) – Quarter X (MMM-
MMM) YYYY,” where X is the number of the quarter, MMM-MMM are the months
included in that quarter, and YYYY is the Calendar Year. This data will be completed by
CMS CO.
2. 	Item 1: Header Row 2, MACs shall enter their Contractor Name and Jurisdiction identifier
in Item 1 of the report.
3. 	Item 2: Header Row 2, MACs shall enter the “Date Report Submitted” to CMS in Item 2 of
the report in MM/DD/YYYY format. [This is the date the report is e-mailed to CMS CO.]
4. 	Item 3: Header Row 2, Report Due. This is the date the report is due to CMS CO. This
date will be completed by CMS CO.
5. 	Item 4: Header Row 3, TCR Contractor Contact (First Name, Last Name, Phone). MACs
shall enter the first and last name of the individual CMS CO should contact to ask
questions regarding information in this report. The contact must be knowledgeable on the
contents of the report.
Detail Rows
Below the Header Rows, Detail Rows shall be completed as follows:
1.Item 5: No. This field contains a consecutive number to track the number of TDLs on the
report. CMS CO will complete this field for all TDLs included on the report by CO. If
the contractor adds additional TDLs, they should continue numbering from the previous
CMS entered row in red font. For example, if CMS included 15 TDLs on the report, the
contractor shall begin numbering in this field with 16 in red font.
2.Item 6: TDL #. CMS CO will complete this field with the TDL number for each public
TDL issued during the quarter.
3.Item 7: CMS Component. CMS CO will complete this field with the CMS Component
responsible for issuing the TDL. [If MACs added the TDL to the report, they do not need
to complete item 7 for those TDLs.]
4.Item 8: Subject. CMS CO will complete this field with the subject for all TDLs issued
during the quarter.

5.Item 9: CMS Issued Date MM/DD/YYYY. CMS CO will complete this field with the
Issued date in MM/DD/YYYY format for all TDLs issued during the quarter.
6.Item 10: Applicable Workload? (“X” or blank). MACs shall complete this field with an
“X” for all TDLs applicable to their workload or leave blank if the TDL is not applicable
to their workload. The TDL is considered applicable to the contractor if any action in the
TDL were required to be completed by the contractor in the reporting period.
7.Item 11: Contractor Compliance? (“Y”, “N” or blank). MACs shall complete this field with
a “y” for all applicable TDLs that the contractor has received, reviewed and complied
with the instructions in the TDL. MACs shall complete this field with a “n” for all
applicable TDLs that the contractor has received and reviewed, but has not complied with
the instructions in the TDL. This field shall remain blank if the TDL is not applicable to
the contractor (i.e. Item 10 is blank).
8.Item 12: Reason for Delay (Leave blank if in compliance). This field shall remain blank if
the TDL has been complied with on or before the due date (i.e. Item 11 is a “y”) or is not
applicable to contractor workload (i.e. Item 11 is blank). If the contractor did not comply
with the instructions in the TDL (i.e. Item 11 is a “n”), the contractor shall select one of
the following reasons from the drop-down list in this field:
01. Due date changed due to TDL
02. Due date changed due to CR
03. System Changes Required to Comply
04. TDL extension approved or pending
05. Deadline past quarter end date
06. Other
01 (Due date changed due to TDL) – Applies only in situations where CMS has issued a
subsequent TDL which corrects and/or replaces previous direction provided under the original
TDL.
02 (Due date changed due to CR) - Applies only in situations where CMS has issued a CR that
supersedes direction provided previously in this specific TDL.
03 (System Changes Required to Comply) – Applies only in the following situations:
a. 	Shared System Maintainer (SSM) production problem prevents a MAC from
completing a specific task in the TDL;
b. 	Non-MAC maintained system (e.g., PECOS, HIGLAS, CWF, etc.) production
problem prevents a MAC from completing a specific task in the TDL;
c. 	MAC is unable to accomplish a specific task in the TDL without SSM system
changes.
04 (TDL extension approved or pending) – Applies only in situations where the CMS
Contracting Officer Representative (COR) has approved an extension of the due date specified in
the TDL.
05 (Deadline past quarter end date) – Applies only in the situations where some or all of the tasks
in the TDL are due to be completed beyond the reporting period of the TCR report.

06 (Other) – Applies in all other situations where compliance with the TDL was delayed, but
Reasons for Delay 01 through 05 does not apply.
9.Item 13: Additional Explanation. MACs shall enter additional comments regarding the
compliance of the TDL in this field if a Reason for Delay is selected in Item 12. Do not
update this field for TDLs complied with timely.
For the following Reasons for Delay (Item 12), MACs shall include the following data in Item
13:
01 (Due date changed due to TDL) – TDL reference number (TDL-######) of the specific TDL
which corrects and replaces the previous TDL. Note the actual date of compliance with the
TDL.
02 (Due date changed due to CR) – CR number and issued date of the CR which supersedes the
TDL. Note the implementation date of the CR.
03 (System Changes Required to Comply) – If a production problem prevents compliance,
provide: name of the system, specific production problem identification number, and resolution
date (if applicable). Note the actual date of compliance with the TDL. If shared system changes
are needed to comply, describe necessary change and any steps taken to notify CMS of the
discrepancy.
04 (TDL extension approved or pending) – Name of the COR, date approval received, and the
revised due date. Note the actual date of compliance with the TDL.
05 (Deadline past quarter end date) – Note specific tasks and the due dates beyond the TCR
reporting period. MACs shall add this TDL to the bottom of the TCR report in red font for the
TCR report of the quarter where MACs completed their work.
06 (Other) – Explanation of the delay for situations not applicable to Reasons for Delay 01
through 05. Use the space allowed in Item 13. If additional space is needed, MACs may submit
with the completed TCR report a separate explanation document. Provide the following
information in a clear and precise manner:
a. 	Cause of the delay;
b. 	If not the entire TDL, reference the specific delayed task;
c. 	Description of specific tasks that were delayed;
d. 	Indicate what is the impact to the government and resolution of the issue with the
TDL implementation;
e. 	Note the actual date of compliance with the TDL.
10. TCR Totals. This section summarizes the totals for the detail rows.
a. 	Item 14 (Total number of TDLs in this report) – This field is calculated. The
contractor shall not update this field. NOTE: this formula sums both TDLs added
by CMS and any additional rows of TDLs added by the contractor on the
spreadsheet.
b. 	Item 15 (Number of TDLs applicable to the contractor) – This field is calculated.
The contractor shall not update this field. NOTE: this formula counts TDLs that
the contractor has indicated are applicable by marking an “x” in Column F.

c. 	Item 16 (Number of applicable TDLs by compliance date) – This field is
calculated. The contractor shall not update this field. NOTE: This formula counts
TDLs that the contractor has indicated were completed timely by marking a “y” in
Column G.
d. 	Item 17 (% of applicable TDLs by compliance date) – This field is calculated.
The contractor shall not update this field. This field reflects the percentage of
applicable TDLs complied with by the due date, regardless of CMS or contractor-
controlled reasons for delay. NOTE: This formula calculates a percentage from
Item 15 and Item 16.
e. 	Item 18 (% of applicable TDLs completed timely) – This field is calculated. The
contractor shall not update this field. This field reflects the percentage of
applicable TDLs complied with timely, regardless of contractor-controlled
reasons for delay, as indicated by a selection of Reason for Delay 6 (Other).
NOTE: This formula calculates a percentage from the total number of Reason for
Delay 06 indicated in Item 19 and the total number of TDLs applicable to the
contractor in Item 15.
11. Each MAC shall complete and submit one TCR report by jurisdiction, a cover
Letter/Attestation Statement (located on tab 1 of the TCR Report Template or in Section
50.3), and if necessary, a separate explanation document. MACs with multiple
jurisdictions may complete a separate sheet within a single Excel workbook for each
jurisdiction. By the quarterly due date, each MAC shall submit the TCR report, via e-mail
to the CMS CO mailbox. [The CMS CO mailbox is: CR_IMPL_REPORTS@cms.hhs.gov.
NOTE: There are no spaces in this Web address. Underscore “_” separates the words
CR_IMPL_REPORTS.] If the report due date of the 28th falls on a weekend or a holiday,
each contractor, including MACs, shall submit the report on the next business day
following the due date.
12. Each MAC shall upload the report to the CMS ART system.
50.1 - CR Implementation Report (CRIR) Template
(Rev. 90, Issued: 02-12-15, Effective: 08-28-14- Begin with Quarter 3 in
2014.Implementation: 08-28-14- Begin with Quarter 3 in 2014)
Upon direction from CMS via a Technical Direction Letter, MACs shall download the updated
CR Implementation Report Template from Electronic Change Information Management Portal
(ECHIMP), Help page. From there, MACs shall click the link from the List of Documents for
the CRIR Template.
50.2 - TDL Compliance Report (TCR) Template
(Rev. 90, Issued: 02-12-15, Effective: 08-28-14- Begin with Quarter 3 in
2014.Implementation: 08-28-14- Begin with Quarter 3 in 2014)
Upon direction from CMS via a Technical Direction Letter, MACs shall download the updated
TCR Template from ECHIMP, Help page. From there, MACs shall click the link from the List
of Documents for the TCR Template.

50.3 - Sample Cover Letter/Attestation Statement
(Rev. 90, Issued: 02-12-15, Effective: 08-28-14- Begin with Quarter 3 in
2014.Implementation: 08-28-14- Begin with Quarter 3 in 2014)
CR Implementation Report
Contractor Name:
Contractor/Jurisdiction Number:
Date Report Submitted to CMS: [MM/DD/CCYY]
Subject: Attestation Statement: Implementation of Change Requests, Qtr.__, FY__ [Include the
appropriate quarter and fiscal year in the Subject line.]
Attention: CMS Central Office (CO) Medicare Contractor Management Group (MCMG)
In accordance with the Centers for Medicare & Medicaid Services (CMS) Change Requests 2884,
6102, and 8598, I attest that all instructions required to be implemented within Quarter __ [1, 2, 3
or 4 – select appropriate quarter] of FY __ [Enter appropriate fiscal year.] have been
implemented. Exceptions are explained in Item 13 of the CR Implementation Report or attached
in a separate document.
Sincerely,
[Name of Contractor Certifying Official.]
[Title of Contractor Certifying Official.]
Technical Direction Letter Compliance Report
Contractor Name:

Contractor/Jurisdiction Number:
Date Report Submitted to CMS: [MM/DD/CCYY]
Subject: Attestation Statement: Compliance with Technical Direction Letters, Qtr.__, FY__
[Include the appropriate quarter and fiscal year in the Subject line.]
Attention: CMS Central Office (CO) Medicare Contractor Management Group (MCMG)
In accordance with the Centers for Medicare & Medicaid Services (CMS) Change Request
8598, I attest that all instructions required to be complied with within Quarter __ [1, 2, 3 or 4 –
select appropriate quarter] of FY __ [Enter appropriate fiscal year.] have been complied with.
Exceptions are explained in Item 13 of the TDL Compliance Report or attached in a separate
document.
Sincerely,
[Name of Contractor Certifying Official.]
[Title of Contractor Certifying Official.]
50.4 - Change Request (CR) Definitions
(Rev. 66, Issued: 01-07-11, Effective: 02-08-11, Implementation: 02-08-11)
50.4.1 - Issue Date
(Rev. 66, Issued: 01-07-11, Effective: 02-08-11, Implementation: 02-08-11)
The date the Centers for Medicare and Medicaid Services (CMS) publishes a change request
(CR).
When a CR has passed through all phases of the change management process, it is then ready for
publication; that is, the CMS is ready to make the instructions contained in the CR available to
contractors, maintainers, providers, beneficiaries and/or any group or organization that may be
affected, as appropriate. The CMS publishes CRs by posting them as Transmittals, on the CMS
Web site.
Note: The issue date is named “Date” on the Transmittal form, One-Time Notification,
Recurring Update Notification, and the Standard CR forms. It is sometimes referred to as the
“transmittal date.”

50.4.2 - Implementation Date
(Rev. 66, Issued: 01-07-11, Effective: 02-08-11, Implementation: 02-08-11)
The implementation date identified in a change request (CR) is the date by which Medicare fee-
for-service contractors and shared system maintainers shall apply all changes detailed in the
business requirements, unless otherwise specified. It is the date when all necessary updates to
infrastructure, business processes and/or supporting technology changes shall be completed and
operational in order to execute new/modified policy and procedure.
For CRs that do not require changes to the shared systems (non-system changes), contractors are
usually given 30 to 90 days from issuance to implement the CR.
For CRs that do require changes to the shared systems (system changes), a date is specified that
usually corresponds with one of the quarterly shared system release dates. The date is usually
the first Monday of the quarter (for example, January 3, April 4, July 5, or October 3 for 2011).
Unless otherwise stated, the implementation date is the same for all business requirements listed
within a specific CR. In some instances, a separate implementation date(s) may be given for a
particular business requirement(s) within a CR.
Implementation and effective dates are frequently not the same. The list below contains the
scenarios for the differences:
• 	The effective date and implementation date are different because the first day of the
quarter is not a Monday;
• 	The effective date and the implementation date are different because the effective date
occurs after the implementation date;
• 	The effective date and the implementation date are different because the effective date
occurs before the implementation date, but both dates are in the future; or
• 	The effective date and the implementation date are different because the effective date
occurs before the implementation date, and the effective date is in the past, while the
implementation date is in the future.
50.4.3 - Effective Date
(Rev. 66, Issued: 01-07-11, Effective: 02-08-11, Implementation: 02-08-11)
The effective date identified in a change request (CR) is the date on which any new rules, laws,
processes and/or policies become active.
Beginning on this date, Medicare contractors shall apply the new rules to process Medicare
claims according to their updated business processes and supporting technology.

The effective date is normally a mandated date resulting from legislation or a regulation. In the
case of National Coverage Determinations (NCDs), the effective date is the first day the item or
service that is the subject of the NCD is covered nationally under the Medicare Program.
Effective dates are not always future dates; sometimes, they are in the past. When this happens,
the Centers for Medicare and Medicaid Services (CMS) instructs contractors, using business
requirements, how to process claims for the period between the effective date and the
implementation date. Typically, the effective date is the first day of any given fiscal year quarter
or the first day of the month.
50.4.4 - Date of Service
(Rev. 66, Issued: 01-07-11, Effective: 02-08-11, Implementation: 02-08-11)
The date of service (DOS) is the date a provider renders service to a beneficiary. Unless
otherwise specified, the effective date of a change request is the date of service.
For the purpose of processing claims, the effective date for applying processing rules, laws,
processes, and/or policies is the date the beneficiary received a service from a provider. For
Durable Medical Equipment (DME) claims with spanned dates of service, the ViPS Medicare
System (VMS) will use only the “From” DOS as the date the supplier rendered a service to a
beneficiary. For example, if a new rule or law became effective on January 1, 2011, and a
beneficiary received service on December 27, 2010, then that service would not be covered
under the new rule. If the beneficiary received the service on or after January 1, 2011, then that
service would be covered by the new rule.
More service-specific information on the Date of Service can be found in. Pub.100-02, Medicare
Benefit Policy Manual and Pub. 100-04, Medicare Claims Processing Manual.
60 - Procedures for Modifying Shared System Edits and Capturing Audit
Trail Data
(Rev. 23, Issued: 05-06-05; Effective: 10-01-05; Implementation: 10-03-05)
POLICY
Contractors must implement processes and procedures for adding, deleting, inactivating,
bypassing or otherwise modifying all shared system edits. Contractors must also have the
capability to document and track those modifications. Modifications to maintainer coded edits
must additionally include documentation that provides the rationale for the modification, the
expected duration of the change, the impact of the change with respect to potential over or
underpayments, claims volumes, effect on providers and / or beneficiaries, etc. In addition, the
claims operations manager or equivalent area manager must document approval of the edit
modification followed by CMS approval before any maintainer coded edit change has been
made.
MACs shall examine their current processes for modifying shared system edits and adjust them
to incorporate the appropriate levels of internal controls. These controls must be documented
and available upon request for review by CMS or an auditor. In addition, contractors must limit
the number of personnel with the security clearance to modify maintainer coded shared system
edits to ten (10).

Should the reason for an edit modification be because of a shared system deficiency, that
associated problem must be documented and reported to the maintainer by the contractor. The
shared system maintainer and contractor must prioritize the appropriate systems changes to
correct edit deficiencies and schedule them for correction as soon as possible via existing change
management processes. Should there not be consensus with the contractors regarding schedule,
CMS maintenance staff should be consulted.
Shared system maintainers must have the capability to track edit changes made by a contractor to
the maintainer coded shared system edits. The shared systems must be able to identify who
modified the edit, what was modified and when the alteration was made.
60.1 - CMS Standard File for Reason Codes
(Rev. 59, Issued: 10-30-09, Effective: 04-01-10, Implementation: 04-05-10)
The A/B MAC (A) or (HHH) Edits Evaluation Workgroup is tasked with identifying the
inventory of contractor inactivated edits, documenting the reasons why the edits are turned off,
and making a decision as to whether they should remain inactive or not. Transmittal 338,
(Change Request (CR) 5927) issued on May 2, 2008, created the ‘CMS Standard’ field within
the existing FISS Reason Code File which contains the status that was determined by the A/B
MAC (A) or (HHH) Edits Evaluation Workgroup for each individual code that was reviewed.
The ‘CMS Standard’ field indicators are as follows:
• 	‘A’ = Active
• 	‘I’ = Inactive
• 	‘ ‘ = Blank
NOTE: The terms ‘Active’ & ‘Inactive‘ are defined as:
• 	Active = Reason code status is equal to ‘S’, ‘P’, ‘ ‘ (blank), ‘D’, ‘R’, ‘T’, or is not
equal to ‘S MDLTD’; and
• 	Inactive = Reason code status is equal to ‘A’ or is equal to ‘S MDLTD.’
Each quarter, as necessary, CMS will issue an updated CMS Standard File for Reason Codes
which is loaded into the system by the FISS maintainer via a Recurring Update Notification.
70 - Change Management Process -- Electronic Change Information
Management Portal (ECHIMP)
(Rev. 100, Issued: 06-23-16; Effective: 07-05-16; Implementation: 07-05-2016)
The Centers for Medicare & Medicaid Services’ (CMS’s) Division of Change Management
(DCM) is responsible for the coordination and distribution of the draft Medicare Fee-for-Service
(FFS) Change Requests (CRs) for Point-of-Contact (POC) Review. To that end, the DCM has
developed the Electronic Change Information Management Portal (ECHIMP), a user-friendly,
Web-based application to streamline and automate the change management process.
In September 2004, the initiators of the CRs began creating and submitting CRs to the DCM via
ECHIMP. In the past, the DCM distributed the draft Medicare FFS CRs to only 15 contractor

POCs and shared system maintainers (SSMs) for POC review. The SSMs forwarded the CRs to
their users for review which increased the time to market the CR and sometimes resulted in the
submission of late comments. Therefore, beginning January 3, 2006, the DCM will continue to
notify the CMS and SSM POCs of the draft Medicare FFS CRs that are in POC review and also
notify all the Medicare FFS contractor POCs as well via ECHIMP 2.0. The DCM will
implement ECHIMP 2.0 on a voluntary basis for its internal CMS staff. Initiators of CRs may
create and submit a CR for POC review using ECHIMP 2.0 beginning January 3, 2006.
However, effective February 6, 2006, ECHIMP 2.0 will be implemented on a mandatory basis
(i.e., all CRs will be initiated, submitted and reviewed in ECHIMP 2.0). The POCs will continue
to receive the POC Review e-mail for CRs initiated and submitted in ECHIMP 1.0 which will
contain the CR and the attachments until February 6, 2006. In addition to receiving the POC
review e-mail with the CR and the attachments, POCs will also receive the POC review e-mail
alert for CRs that are initiated and submitted in ECHIMP 2.0 which will not contain the CR file
and the attachments. However, these e-mail alerts will contain a link for the POCs to click to
review and submit comments on the CR via ECHIMP 2.0.
NOTE: Beginning February 6, 2006, contractors and maintainers should not reply to any e-
mails from ECHIMP @cms.hhs.gov nor should they send any e-mail to eChimp@cms.hhs.gov.
Effective February 6, 2006, we will not accept any e-mails sent to that address.
The notification of the draft Medicare FFS CRs will be distributed via an E-mail from ECHIMP
to the CMS, contractor and SSM POCs, which will no longer contain the files and documents
associated with the draft CR. Once the POCs receive the e-mail notification from ECHIMP that
notifies them that a CR is currently in POC review, they shall log in to ECHIMP via a link that
will be provided in the E-mail notification. Once logged in, they shall review the draft CR and
provide comments to CMS via ECHIMP by the POC Review Comment due date. To maintain
as much efficiency as possible with such a large number of prospective reviewers, each POC
may submit only one set of comments on behalf of their contractor or maintainer organization
and that submission must be identified as such. If the CR impacts A/B MAC (A), A/B MAC
(B), DME MAC and/or A/B MAC (HHH) and it makes more sense to submit the comments
separately (to keep the content clear), then two sets of comments from the contractor site or
maintainer organization will be acceptable. No response received will be considered a
concurrence. NOTE: It is the responsibility of the POCs to notify appropriate staff that a CR has
entered POC review and to share the information with them. Each individual who has access to
ECHIMP will also have the ability to review, download and print the CR files and share the files,
either electronically or hardcopy, with other staff members who do not have ECHIMP access.
We believe that expanding the POC review process to all of the Medicare FFS contractors and
SSMs will not only decrease the time to market the CRs, but will also increase the quality of the
review of the CRs by allowing a wider audience of those potentially impacted by the change the
opportunity to comment. We also believe that this expansion to the POC review process will
reduce the number of late comments submitted as well as reduce the number of corrected CRs
now necessary as a result of uncoordinated and/or untimely POC comments.
CMS realizes that expanding the POC review process to all of the Medicare FFS contractors and
SSMs could potentially cause a lack of efficiency and an administrative burden if the above-
outlined POC review process is not adhered to. Therefore, we will pilot this expanded POC
review process for approximately 3 months effective February 6, 2006. At the conclusion of the
3 months, we will evaluate the pilot and adjust the POC review process, if necessary.

Change Request Correction and Rescind Process
Currently, the CR corrections and rescind process is a manual process, which is completed via
email. CMS is automating the CR correction and rescind process utilizing the ECHIMP system.
This CR implements the following processes:
• 	CMS will begin distributing Medicare FFS CRs that are being corrected or rescinded for
review via a notification from ECHIMP to the current POC Review recipients. These
notifications will specify the type of review to be performed in the subject line of the
email (i.e., POC, Correction or Rescind Review). All current POC Review recipients will
receive the notifications whether they are impacted on the CR or not. The notifications
will specify which Medicare Administrative Contractors (MACs) and Shared System
Maintainers (SSMs) are impacted.
• 	Impacted SSMs will review and comment on CRs during the CR's Correction or Rescind
Review Period.
• 	Impacted SSMs will update their estimates as a result of the correction or rescind.
• 	Non-impacted SSMs and non-impacted MACs will be able to review and comment on
the draft corrected or draft rescinded CRs in ECHIMP, if they so choose.
CRs that have been corrected and rescinded prior to this automation will not be updated in
ECHIMP. This process will apply to CR corrections and Rescinds initiated on or after July 5,
2016.
80 - Contractor Workload Transitions
(Rev.108, Issue: 11-03-17, Effective: 12-04-17, Implementation: 12-04-17)
Fee-for-Service contractor workload transitions occurred when a Medicare Administrative
Contractor’s (MAC’s) period of performance ends or its contract is terminated. When either of
these two circumstances occurs, the outgoing contractor is required to work with the new
incoming contractor to transfer the Medicare workload without any disruption to providers and
beneficiaries.
During a transition, the outgoing contractor has responsibilities and processes for closing out its
Medicare contract and shutting down its operation. It must also assist the new incoming
contractor in its efforts to assume the Medicare claims administration functions. Concurrently,
the incoming contractor is required to establish an operational infrastructure and ensure that all
data, records, and functions are properly transferred from the outgoing contractor. Both parties
have a responsibility to ensure that the transition is conducted seamlessly and that all contractual
obligations are met during the transition.
80.1 - Transition Handbooks
(Rev.108, Issue: 11-03-17, Effective: 12-04-17, Implementation: 12-04-17)

The Medicare Contractor Management Group (MCMG) in the Center for Medicare has
developed a handbook in order to assist fee-for-service contractors with the transfer of Medicare
workload from one contractor to another. This is found at:
https://www.cms.gov/Medicare/Medicare-Contracting/Medicare-Administrative-
Contractors/Resources-for-MACs.html
Every Medicare workload transition will vary depending on the unique circumstances and
environment of the Medicare contractors involved. There may be activities and processes
described in the handbooks that, for various reasons, will not be applicable to a specific
transition. There may also be activities that will need to be performed that the handbooks do not
cover. The handbook cannot identify and address all of the variations that may occur during a
workload transition. However, the overall activities described in the handbooks for managing a
workload implementation or closeout project and the requirements contained therein for
meetings, reporting, and providing information, data, and records are part of the IOM and
incorporated by reference into the MAC contracts.
90 - Integrated Data Repository (IDR) Claims Sourcing from Shared Systems
(Rev. 54, Issued: 10-01-08; Effective: 10-01-08; Implementation: 01-05-09)
The CMS’ fraud investigation landscape is significantly different today than in the past as a
result of program changes, such as the implementation of the Medicare Prescription Drug
benefit, competitive selection of contractors responsible for claims administration and program
integrity, such as Medicare Administrative Contractors (MACs) and PSCs, expansion of Medi-
Medi and Recovery Audit Contractor (RAC) programs, and advent of the Medicaid Integrity
Program (MIP). CMS recognizes the need to significantly enhance the use of technology to
improve its collaborative fraud fighting efforts as well as to establish a modernized data analysis
capability for all of Program Integrity.
Today, most Program Integrity contractors have built their own data warehouses and/or avenues
for collecting, processing, analyzing data which serves their own individual needs. These
distributed, regional approaches to data analysis do not lend themselves to national analyses, do
not represent best practices, and do not take advantage of the cost savings that a centralized data
repository would provide. All of these functions can be better served through a comprehensive
set of common data structures and modern tools that encourage collaboration and innovation.
The IDR goal - through incremental releases - is to be the centralized data repository for all
Medicare data. The Program Safeguard Contractors (PSCs) cannot currently use the IDR
exclusively because the source of claims data is the National Claims History (NCH). The limited
NCH data record is inadequate to support the extensive fraud, waste and abuse investigations
that need to be performed by PSCs. The Shared Systems data are the required data source for
Program Integrity. The CR initiates the acquisition of the Shared Systems data for the IDR.
Once the IDR has the required Shared Systems data, Program Integrity and their contractors will
increase their ability to detect potential fraud, waste and abuse.
FISS shall provide, in electronic format, all claims output for all A/B MACs (A) or (HHH) and
claim types on a daily basis at the claims header and detail level for each of the three identified
lifecycle phases required.

MCS shall provide, in electronic format, all claims output for all A/B MACs (B) and claim types
on a daily basis at the claims header and detail level for each of the three identified lifecycle
phases required.
VMS shall provide, in electronic format, all claims output for all DME MACs and Certificates of
Medical Necessity, as required with certain claims for payment, on a daily basis at the claims
header and detail level for each of the three lifecycle phases required.
The IDR Lifecycle Phase I is defined as the claim upon enumeration. The IDR Lifecycle Phase
II is defined as the claim immediately after CWF adjudication. The IDR Lifecycle Phase III is
defined as the claim once financial information has been posted to it.

Transmittals Issued for this Chapter
Rev # 	Issue Date 	Subject 	Impl Date 	CR#
R13718GI 	04/10/2026 Records and Information Management
Requirements Updates to Pub. 100-01,
Medicare General Information, Eligibility
and Entitlement Manual, Chapter 7,
Section 30
09/14/2026 	14324
R11395GI 	05/04/2022 	Updated Instructions for the Change
Request Implementation Report (CRIR)
and Technical Direction Letter (TDL)
Compliance Report (TCR)
05/31/2022 	12714
R128GI 	11/01/2019 	Update to General Information, Eligibility,
and Entitlement, Chapter 7 - Contract
Administrative Requirements, Section
40.2 – Shared System Maintainer
Responsibilities for Systems Releases
12/03/2019 	11518
R125GI 	07/05/2019 	Internet Only Manual (IOM) - Update to
General Information, Eligibility, and
Entitlement, Chapter 7 - Contract
Administrative Requirements, Section
40.2 – Shared System Maintainer
Responsibilities for Systems Releases,
Section 40.3.11 Single Testing Contractor
(STC) Non-Testable Conditions and
Potential Testing Impacts
08/05/2019 	11245
R124GI 	05/17/2019 	Update to Publication (Pub.) 100-01 to
Provide Language-Only Changes for the
New Medicare Card Project
06/18/2019 	11240
R122GI 	12/21/2018 	Updated Instructions for the Change
Request Implementation Report (CRIR)
and Technical Direction Letter (TDL)
Compliance Report (TCR)
05/28/2019 	11067
R108GI 	11/03/2017 	MAC Transition Workload Handbook 	12/04/2017 	10329
R105GI 	06/02/2017 	Update to General Information, Eligibility,
and Entitlement, Chapter 7 - Contract
Administrative Requirements, Section 40
– Shared System Maintainer
Responsibilities for Systems Releases
07/03/2017 	10062

R102GI 	11/02/2016 	Internet Only Manual (IOM) Publication
100-01 - General Information, Eligibility,
and Entitlement, Chapter 7 - Contract
Administrative Requirements, Section 40
– Shared System Maintainer
Responsibilities for Systems Releases
11/02/2016 	9785
R100GI 	06/23/2016 	Medicare Fee-for-Service Change Request
Correction and Rescind Process
07/05/2016 	9455
R99GI 	06/10/2016 	Medicare Fee-for-Service Change Request
Correction and Rescind Process –
Rescinded and replaced by Transmittal
100
06/10/2016 	9455
R97GI 	01/15/2016 	Internet Only Manual (IOM) Publication
100-01 - General Information, Eligibility,
and Entitlement, Chapter 7 - Contract
Administrative Requirements, Section 40
– Shared System Maintainer
Responsibilities for Systems Releases
09/21/2015 	9219
R95GI 	10/16/2015 	Internet Only Manual (IOM) Publication
100-01 - General Information, Eligibility,
and Entitlement, Chapter 7 - Contract
Administrative Requirements, Section 40
– Shared System Maintainer
Responsibilities for Systems Releases –
Rescinded and replaced by Transmittal 97
09/21/2015 	9219
R93GI 	08/21/2015 	Internet Only Manual (IOM) Publication
100-01 - General Information, Eligibility,
and Entitlement, Chapter 7 - Contract
Administrative Requirements, Section 40
– Shared System Maintainer
Responsibilities for Systems Releases –
Rescinded and replaced by Transmittal 95
09/21/2015 	9219
R90GI 	02/12/2015 	Rescinds/Replaces CR 7468 - Updated
Instructions for the Change Request
Implementation Report (CRIR) and
Technical Direction Letter (TDL)
Compliance Report (TCR)
05/28/2015 	8598
R88GI 	08/25/2014 	Rescinds/Replaces CR 7468 - Updated
Instructions for the Change Request
Implementation Report (CRIR) and
Technical Direction Letter (TDL)
09/11/2014 	8598

Compliance Report (TCR) – Rescinded
and replaced by Transmittal 90
R87GI 	08/08/2014 	Update to Pub. 100-01, Chapter 7 for
Language-Only Changes for ICD-10
Upon
Implementati
on of ICD-10
8639
R86GI 	05/16/2014 	Rescinds/Replaces CR 7468 - Updated
Instructions for the Change Request
Implementation Report (CRIR) and
Technical Direction Letter (TDL)
Compliance Report (TCR) – Rescinded
and replaced by Transmittal 88
08/28/2014 	8598
R83GI 	03/07/2014 	Update to Pub. 100-01, Chapter 7 for
Language-Only Changes for ICD-10 –
Rescinded and replaced by Transmittal 87
10/01/2014 	8639
R75GI 	12/30/2011 	Contractor Implementation of Change
Requests and Compliance With Technical
Direction Letters – Rescinded and
replaced by CR 8598
05/28/2012 	7468
R66GI 	01/07/2011 	Change Request (CR) Definitions 	02/08/2011 	6592
R59GI 	10/30/2009 	The CMS Standard File for Reason Codes
for the Fiscal Intermediary Shared System
(FISS)
04/05/2010 	6529
R57GI 	02/20/2009 	Implementing Validated Workarounds for
Share System Claims Processing by
Medicare Administrative Contractors
(A/B MACs), Durable Medical Equipment
Medicare Administrative Contractors
(DMEMACs). Carriers, Regional Home
Health Intermediaries (RHHIs) and Fiscal
Intermediaries
03/20/2009 	6379
R54GI 	10/01/2008 	IDR Claims Sourcing From Shared
Systems-Implementation
01/05/2009 	5949
R53GI 	09/26/2008 	Medicare Contractor Testing with Future
Dates in the EDC
10/27/2008 	6110
R52GI 	07/11/2008 	Change to CR Implementation Report Due
Dates
08/11/2008 	6102
R51GI 	05/16/2008 	IDR Claims Sourcing From Shared
Systems-Implementation - Rescinded and
Replaced by Transmittal 54
10/06/2008 	5949

R46GI 	07/20/2007 	Implement New Contractor ID for Single
Testing Contractor (STC)
01/07/2008 	5648
R44GI 	05/25/2007 	Fee-for-Service Contractor Transition
Handbooks
07/02/2007 	5446
R43GI 	03/30/2007 	Clarification in Testing Instructions for
Definition of “Local Components”
07/02/2007 	5395
R38GI 	05/26/2006 	Files Maintenance Program Update to the
Internet-Only Manual (IOM)
06/26/2006 	5055
R34GI 	01/06/2006 	Change Management Process -- Electronic
Change Information Management Portal
(eChimp)
01/03/2006 	4092
R33GI 	12/30/2005 	Change Management Process -- Electronic
Change Information Management Portal
(eChimp)
01/03/2006 	4092
R30GI 	10/28/2005 	Initiate STC testing of the MCS for RRB
and HIGLAS
04/03/2006 	4150
R26GI 	07/22/2005 	Implement New Medicare Plan ID and
Carrier Number for the Single Testing
Contractor (STC)
10/03/2005 	3978
R25GI 	07/15/2005 	Next Generation Desktop (NGD) Testing
Requirements
08/15/2005 	3493
R24GI 	05/27/2005 	2005 Scheduled Release for July Updates
to Software Programs and Pricing/Coding
Files
06/27/2005 	3865
R23GI 	05/06/2005 	Procedures for Modifying Shared Systems
Edits and Capturing Audit Trail Data
10/03/2005 	3862
R17GI 	02/25/2005 	Review of Contractor Implementation of
Change Requests (Replacement for
expired CR 944)
03/01/2005 	2884
R16GI 	01/28/2005 	Standard Terminology for Claims
Processing Systems
04/04/2005 	3596
R15GI 	01/21/2005 	Review of Contractor Implementation of
Change Requests (Replacement for
expired CR 944)
03/01/2005 	2884
R08GI 	07/30/2004 	Establish Standard Terminology for
Medicare Shared Systems
01/03/2005 	3086

R06GI 	05/2//2004 	CMS Policy for Testing Quarterly Release
of the Medicare Shared Systems and the
CWF
08/01/2004 	3011
R05GI 	05/07/2004 	Initial Publication of Chapter 	N/A 	2765
Back to top of Chapter