General Information, Eligibility, and Entitlement 
Manual 
Chapter 7 - Contract Administrative Requirements 
 
Table of Contents 
(Rev. 128, 11-01-19) 
 
Transmittals for Chapter 7 
10 - Contracting and Subcontracting  Not yet available 
20 - Publishing by Contractors and Restrictions on Promotional Activity  Not yet available 
30 - Files Maintenance 
30.10 - Files Maintenance Program - General 
30.10.1 - Description of Records Maintained 
30.10.2 - Definition of a Record 
30.20 - Implementing a Files Management Program 
30.30 - Record Retention and Disposal Schedule 
30.30.1 - Disposition Instructions - Destruction of Records 
30.30.1.1 - Disposition Instructions When Operating Under a Freeze 
30.30.1.2 - Disposition Instructions When Medicare Records are 
Microfilmed 
30.30.1.3 - Disposition for Paper-Only Medicare Records 
30.30.1.4 - Disposition for Medicare Records that are Imaged/Scanned 
30.30.1.5 - Disposition for Medicare Records When Potential Fraud or 
Overutilization has been Identified 
30.30.2 - Description of Records 
30.40 - Retention of Claims File Materials 
30.40.1 - Segment File Accumulation Period 
30.40.2 - Standard Retention Periods - Microfilmed Claims 
30.40.3 - Retention Period Microfilmed Material 
30.50 - Microfilming of Files Material 
30.50.1 - Microfilming Procedures 
30.50.2 - Microfilming Index Label 
30.50.3 - Retention and Destruction of Microfilm 
30.60 - Annual Report of Medicare Records  30.70 - Disposition of Non-Claims Materials 
30.80 - Standards for All Records Storage Facilities 
30.90 - Exhibits 
Exhibit 1 - Preprinted Container Label 
Exhibit 2 - Minimum Label Data Required for Unlabeled Boxes 
Exhibit 3 - Records Transmittal and Receipt - Standard Form 135 
Exhibit 4 - Reference Request - Federal Records Center - Optional Form 11 
Exhibit 5 - Certificate of Authenticity - START 
Exhibit 6 - Certificate of Authenticity - END 
Exhibit 7 - Correction Card 
Exhibit 8 - Start of Retake or Addition Certificate 
Exhibit 9 - Retake or Addition Certificate 
Exhibit 10 - Resolution Test Chart 
Exhibit 11 - Witness Disposal Certification (Sample) 
Exhibit 12 - Roll Report 
Exhibit 13 - Report of Medicare Records 
Exhibit 14 - Inspection Checklist--Standards for Records Storage Facilities 
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 - Files Maintenance 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
30.10 - Files Maintenance Program - General 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
Subject to the provisions of the Code of Federal Regulations, Title 41, Part 102 - Creation, 
Maintenance and Use of Records, http://www.access.gpo.gov/nara/cfr/waisidx_05/41cfr102-
193_05.html CMS has the responsibility for the development and implementation of standards 
and programs for the economical management of records under the health insurance program.  
Specifically, CMS is required to provide for effective controls over the creation of records, 
including the making of records containing adequate and proper documentation of the 
contractor's administration and operations.  Each contractor is required to establish and maintain 
an active, continuing program for the economical and efficient management of the records 
outlined in 30.20. 
 
The contractor's programs must provide for: 
 
  Effective controls over the creation, the organization, maintenance and use, and disposition 
of all CMS health insurance claims and non-claims records; and 
 
  Development and application of standards, procedures, and techniques designed to assure 
the maintenance and security of records of continuing value and facilitate the disposal of 
all records of temporary value. 
 
The contractor provides for the continued analysis and improvement of record classification and 
indexing systems, the use of filing equipment and supplies, and the reproduction and 
transportation of records.  The contractor assures that records are maintained economically and 
efficiently for maximum usefulness. 
 
The files established by the contractor, and all records and procedures documenting its programs 
for controlling the creation, maintenance, and use of current records, for the selective retention of 
records of continuing value, and for the disposal of noncurrent records, must be available for 
periodic review by CMS. 
 
Under no circumstances are any records identified by CMS as relating to a current investigation 
or litigation/negotiation by the Office of the Inspector General or the Department of Justice, 
ongoing Workers Compensation, set aside arrangements, or documents which prompt 
suspicions of fraud and abuse of overutilization of services to be destroyed.  These records must 
be retained until you receive authorization from CMS. 
 
30.10.1 - Description of Records Maintained 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
A. Claims Records 
 
These are Government records including Government-issued standard forms and other forms, 
documents, and statements needed to support claims.  Such records are maintained by the  contractor in accordance with instructions regarding retention, transfer, destruction, and other 
disposition of claims materials.  (See 30.30 and 30.40.) 
 
B. Non-Claims Records 
 
These include materials not needed as supporting documentation of a claim, such as used work 
sheets, extra copies of documents, retained CMS bill copies where records were submitted on 
tape, used punched cards, EDP listings, used paper tape, and general correspondence not related 
to specific pending or processed claims.  See 30.30 for the records retention and disposal 
schedule and 30.70 for the disposition of such material. 
 
C. Fiscal and Administrative Records 
 
These include records that are not included as claims or non-claims records.  See 30.70 for the 
records retention and disposal schedule. 
 
D. Microform Records 
 
This is a term used for any form containing micro-images (e.g., microfilm, microfiche).  If 
records are microfilmed, the original records must still be retained. 
 
E. Scanned/Imaged Records 
 
This is a term used for any information that is recorded in a form that only a computer can 
process.  This is the preferred format when paper records are not retained.  The image becomes 
the official record/recordkeeping copy which must be retained in accordance with directives 
from CMS. 
 
30.10.2 - Definition of a Record 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
Records are basically files consisting of papers, folders, photographs, photographic copies, 
magnetic tapes, or other recorded information regardless of physical form or characteristics, 
accumulated or maintained in filing equipment, boxes, disks, CDs or shelves, and occupying 
office or storage space.  Stocks of publications and blank forms are not included in this 
definition. 
 
30.20 - Implementing a Files Management Program 
(Rev. 124, Issued: 05-17-19, Effective: 06-18-19, Implementation: 06-18-19 
 
The term Medicare beneficiary identifier (Mbi) is a general term describing a beneficiary's 
Medicare identification number. For purposes of this manual, Medicare beneficiary identifier 
references both the Health Insurance Claim Number (HICN) and the Medicare Beneficiary 
Identifier (MBI) during the new Medicare card transition period and after for certain business 
areas that will continue to use the HICN as part of their processes. 
 
Adequate records management controls over the creation of contractor files must insure that 
important policies and decision are adequately recorded, routine operational paper work is kept 
to a minimum, and the accumulation of unnecessary files is prevented.  Effective techniques in  this area include the application of systems for the control of correspondence and forms, the 
minimizing of duplicate files, and the disposal without filing of transitory material that has no 
value for record purposes. 
 
CMS expects each contractor to establish an appropriate program for the management of its files.  
The following actions are generally basic to such a files management program. 
 
A. Standardize classification and filing schemes to: 
 
1. Achieve maximum uniformity and ease in maintaining and using program records; 
 
2. Facilitate disposal of records in accordance with applicable records disposal schedules; 
and 
 
3. Facilitate possible later consolidation of identical type files presently maintained at 
different locations. 
 
B. Formally authorize official file locations.  Prohibit the maintenance of files at other than 
authorized locations. 
 
C. Standardize reference service procedures to facilitate the finding, charge-out, and refiling of 
records. 
 
D. File accumulations of papers received at file locations on a daily basis. 
 
E. Audit periodically a representative sample of the files for duplication, misclassification, or 
misfiles.  In addition to the above, the contractor's program must: 
 
1.  Establish and implement standards and procedures issued by CMS.  Such CMS standards 
and procedures relate to: 
 
a. Classifying, indexing, and filing records; 
 
b. Providing reference services to filed records; 
 
c. Locating active files to facilitate use of the records; and 
 
d. Reviewing the program periodically to determine the adequacy of the system and its 
effectiveness in meeting requests. 
 
2.  Ensure that the standards, guides, and instructions developed for the files management 
program are readily available to all employees concerned with the files operations.  In 
addition, give pertinent information for users of files and references services the widest 
possible dissemination. 
  3.  File accumulations of papers received at file locations on a daily basis. 
 
4.  Audit periodically a representative sample of the files for duplications, misclassification, 
or misfiles. 
 
The methods used in maintaining, using, and disposing of these files vary with the contractor.  
Variations depend on the filing and control methods established (e.g., provider number, 
Medicare beneficiary identifier, date, name, or other sequence) to record requests from 
providers; to furnish replies; to check on overdue cases; to control cases for completion of 
processing; to control cases requiring some type of investigation or additional documentation; to 
retain completed cases for history or other reference; to maintain for audits; and to schedule for 
transfer to other storage areas.  Other variances may be due to computer or clerical practices; 
workload volume; review initiated at time of notice of admission, at time of start of care, at time 
of request for advance payment or at time of receipt of billing form; and other considerations. 
 
30.30 - Record Retention and Disposal Schedule 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
This schedule identifies those records accumulated by the contractor in administering the 
Medicare program and outlines the disposal schedule for each type of record. 
 
A freeze has been imposed on the destruction of Medicare records.  No paper Medicare records 
can be destroyed unless they are electronically imaged.  If Medicare records are not imaged, the 
original paper document must be retained.  A contractor who images paper Medicare records: 
 
A.  Must always be able to demonstrate the imaged version is an exact copy of the paper 
document, 
 
B.  Document the steps taken to image the original document, 
 
C.  Establish and implement a certification/quality assurance process to ensure the imaged 
information is an identical replication of the paper document in every way, 
 
D.  Retain the scanned image as the recordkeeping copy for the required retention period, 
and 
 
E.  Maintain accessibility and the ability to read the document in accordance with changes in 
technology. 
 
The methods used in imaging files may vary with the contractor.  These variations depend on the 
type of equipment used and methods used to prepare documents for imaging.  All imaged 
documents shall be tamper proof.  Once an image is verified as an exact copy of the original 
paper document, only then can the original paper document be destroyed and the imaged copy is 
certified as the recordkeeping copy. 
 
Certifying images as an exact copy of the paper document means there is a "quality assurance" 
process in place that verifies that the images are good.  Each contractor is responsible for 
establishing their own "quality assurance" procedures.   
Below is an example of a certification/quality assurance process. 
 
1.  The staff member performing the actual scan will: 
 
a.  Observe that all pages successfully pass through scanner and that image displayed 
on the imaging software preview screen appear accurate. 
 
b.  Affix a sticker marked Scanned to the top page, write the current date on the 
sticker and place on top of a pile of scanned material. 
 
2.  The staff member(s) responsible for these records will have immediate access to the 
images, from their desktops, using the imaging software.  They will have 30 days to 
use and review the images.  If any problem is detected, the paper will be retrieved and 
rescanned.  After 30 days, the paper copies are subject to proper disposal. 
 
A contractor is authorized to cut off and transfer Medicare claims records and other records to 
inactive storage earlier than is prescribed in the disposal schedule shown below when the records 
are contained on microform.  (See 40.3 and .50ff. for guidelines on retention and disposition 
guidelines on microform copies of the following records.) 
 
The term "cut off" means the transfer of records to an inactive files area when there is no more 
than one reference to a file drawer per month.  See 30.70 for guidelines regarding the 
disposition of non-claims material not transferred to inactive storage. 
 
30.30.1 - Disposition Instructions - Destruction of Records 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
In accordance with Federal regulations, 36 CFR 1228.58(b)-Destruction of Temporary Records, 
http://www.access.gpo.gov/nara/cfr/waisidx_05/36cfr1228_05.html paper records to be disposed 
of normally must be sold as wastepaper.  Because the records you maintain are considered 
restricted, you are required to pulp, macerate, shred, or otherwise definitely destroy the 
information contained in the records and their destruction must be witnessed by you who created 
the records or by a contractor employee (see Exhibit 11, Witness Disposal Certification-Sample).  
The contract for sale must prohibit the resale of all other paper records for use as records or 
documents.  Regardless of medium, records other than paper records (e.g., audio, visual, data 
tapes, disks, diskettes, etc.) may be salvaged and sold in the same manner and under the same 
conditions as paper records. 
 
A Witness Disposal Certification must be completed and kept on file for 7 years. 
 
30.30.1.1 - Disposition Instructions When Operating Under a Freeze 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
When operating under a freeze, you are prohibited from destroying records, and must follow the 
disposition instructions below in 30.30.1.2.  Only after the freeze has been lifted, can you revert 
back to the normal disposition instructions in 30.30.2. 
 
30.30.1.2 - Disposition Instructions When Medicare Records are Microfilmed  (Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
Paper Records 
 
All paper claims that are microfilmed must be retained until CMS notifies you the freeze is 
lifted. 
 
Microform Records 
 
The master microform must be retained until CMS notifies you the freeze is lifted. 
 
30.30.1.3 - Disposition For Paper-Only Medicare Records 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
The contractor cuts off the file at the close of the calendar year in which the claim was paid, then 
transfers the paper records to inactive storage.  The paper records must be retained until CMS 
notifies you the freeze is lifted. 
 
30.30.1.4 - Disposition For Medicare Records that are Imaged/Scanned 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
Paper 
 
Since imaging can be used to replace paper documents, only when the image will be identical to 
the paper, you must image/scan both the front and the back of every document. 
 
There is an exception:  Once the back of a claim form is imaged, you do not have to image 
the back of the rest of the documents imaged on that particular machine, as long as the 
backs are identical and a certified statement is kept on file stating the remainder of the 
backs of the claim forms are identical.  However, if the back of a claim form differs in any 
respect, it must be imaged. 
 
The contractor must retain the paper records until their certification/quality assurance process 
(see below) has been completed and the imaged information (the recordkeeping copy) is verified 
as an identical replication of the paper document.  Only then can the paper records be destroyed. 
 
If a scanned document is not identical to the paper document, that paper document must be 
retained until the freeze is lifted. 
 
Imaged/Scanned Records 
 
Due to the freeze prohibiting the destruction of Medicare records, do not destroy any images of 
claims records.  They are the recordkeeping copy and must be retained until CMS notifies you 
the freeze is lifted.  Once the freeze is lifted, revert back to the normal disposition instructions in 
30.30.2. 
 
Sample Quality Assurance Procedure 
  Certifying images as an exact replication of the paper document means there is a "quality 
assurance" process in place that verifies that the images are good.  Each contractor is responsible 
for establishing their own "quality assurance" procedures.  Below is an example of a quality 
assurance process. 
 
Standard Procedures for Document Imaging Quality Assurance 
 
1.  The staff member(s) performing the actual scan will: 
 
a. Observe that all pages successfully pass through scanner and that image 
displayed on the imaging software preview screen appear accurate. 
 
b. Affix a sticker marked Scanned to the top page, write the current date on 
the sticker and place on top of a pile of scanned material. 
 
2.  The staff member(s) responsible for these records will have immediate access to the 
images, from their desktops, using the imaging software.  They will have 30 days to 
use and review the images.  If any problem is detected, the paper will be retrieved and 
rescanned.  After 30 days, the paper copies are subject to proper disposal. 
 
30.30.1.5 - Disposition for Medicare Records When Potential Fraud or 
Overutilization Has Been Identified 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
When potential fraud or overutilization has been identified, retain the recordkeeping copy onsite.  
If the recordkeeping copy has already been transferred to offsite storage, retrieve and retain 
onsite until the investigation and subsequent legal action, if any, has been completed (including 
the exhaustion of all appeals), then destroy 3 months thereafter. 
 
If at the close of this period, the disposition instructions shown in 30.30.1.1 through 30.30.2 
remains applicable, retain, transfer, and destroy in accordance with the disposition instructions.  
If the disposition instructions in 30.30.1.1 through 30.30.2 are no longer applicable, then 
destroy after the 3 month period following completion of the investigation or subsequent legal 
action, if any. 
 
If any records are provided to a prosecutorial agency as evidentiary matter, consider such records 
as disposed of.  If any such record is returned by the prosecutorial agency, retain for 3 months, 
then destroy in accordance with the foregoing disposition instructions unless otherwise directed 
by the prosecutorial agency. 
 
30.30.2 - Description of Records 
(Rev. 124, Issued: 05-17-19, Effective: 06-18-19, Implementation: 06-18-19 
 
The term Medicare beneficiary identifier (Mbi) is a general term describing a beneficiary's 
Medicare identification number. For purposes of this manual, Medicare beneficiary identifier 
references both the Health Insurance Claim Number (HICN) and the Medicare Beneficiary 
Identifier (MBI) during the new Medicare card transition period and after for certain business 
areas that will continue to use the HICN as part of their processes. 
  1. Medicare Claims Records: 
 
A. A/B MAC (A) or (HHH) Billing Records (FROZEN - DO NOT DESTROY) 
 
These files consist of Inpatient and/or Outpatient Billing forms, and other documents 
used to bill for services processed by A/B MACs (A) or (HHH) i.e., inpatient hospital, 
outpatient hospital, SNF, hospice, home health, etc. 
 
DISPOSITION:  Once the freeze is lifted, cutoff at the close of the CY in which paid.  
Destroy 6 years and 3 months after cutoff. 
 
B. A/B MAC (B) or DME MAC Billing Records (FROZEN - DO NOT DESTROY) 
 
These files consist of Requests for Payment and similar forms.  Also included are 
itemized bills, correspondence (including correspondence with district offices), and 
comparable documents used to support payment to beneficiaries, physicians, and other 
suppliers of services under the Supplemental Medical Insurance (SMI) Program. 
 
DISPOSITION:  Once the freeze is lifted, cutoff at the close of the CY in which paid.  
Destroy 6 years and 3 months after cutoff. 
 
2. Medicare Benefit Check Records (FROZEN - DO NOT DESTROY) 
 
These files consist of paid checks that contractors receive from banks covering amounts paid to 
providers of service, beneficiaries, physicians, and other suppliers of service under the Hospital 
Insurance and Supplementary Medical Insurance (SMI) programs.  Also included are check 
vouchers and cancelled or voided checks resulting from nonreceipt, loss, theft, or non-delivery. 
 
Disposition:  The contractor cuts off the file at the close of the calendar year in which issued, 
holds the file for 1 additional year, and then transfers it to inactive storage.  Once the freeze is 
lifted, the file is destroyed after a total of 6 years and 3 months retention. 
 
When fraud or overutilization of services is involved, the contractor retains the hard copy claim 
until 3 months after the resolution of the investigation OR reverts to normal disposition, 
whichever is longer. 
 
3. Medicare Summary Notices (MSNs) (FROZEN - DO NOT DESTROY) 
 
These files consist of MSNs used to advise beneficiaries about remaining Part A benefits, Part A 
and Part B deductible status, and about applying for complementary health benefits. 
 
Disposition:  The contractor cuts off the file at the close of the calendar year in which benefit 
was paid or denied, as applicable, holds for 1 additional year and then transfers to inactive 
storage.  Once the freeze is lifted, remove them from inactive storage for destruction after a total 
of 6 years and 3 months retention from cut off. 
 
4. Reconsideration and Hearing Case Files - Hospital Insurance Program (FROZEN - DO 
NOT DESTROY) 
  Reconsideration records accumulate when a beneficiary or their representative is dissatisfied 
with the A/B MAC (A) or (HHH)'s determination denying payment, or with the amount of 
benefits payable on the beneficiary's behalf under the Hospital Insurance Program and files either 
an expressed or implied request for reconsideration.  Hearing case records accumulate when a 
beneficiary or their representative is dissatisfied with the reconsideration determination and 
requests a hearing; and if still dissatisfied after the hearing, files for a subsequent court review. 
Included are Forms CMS-2649, Request for Hearing; CMS-561, Request for Reconsideration; or 
their equivalents.  Also included are evidence furnished by beneficiaries or their representatives, 
correspondence, CMS determinations, Administrative Law Judge decisions, original bills, 
Appeals Council decisions and similar material. 
 
Disposition:  Once the freeze is lifted, the contractor disposes of these records in accordance with 
instructions for Medicare claims records. 
 
5. Review and Fair Hearing Case Files - Supplementary Medical Insurance Program 
(FROZEN - DO NOT DESTROY) 
 
This category includes files accumulated when a beneficiary, physician, provider, or other 
supplier of service is dissatisfied with the MACs determination denying a request for payment, 
or with the amount of the payment, or with the reasonable promptness of action on a request for 
payment.  Included are copies of claimant's requests for review, relevant written statements or 
evidence, notices of adverse formal review decisions, requests for hearings to protest the adverse 
decisions, hearings proceedings, hearing officers' final decisions, and other comparable papers. 
 
Disposition:  The contractor places these records in an inactive file upon final action on the case.  
It cuts off the inactive file at the close of the calendar year in which the final action was taken, 
and holds it for 2 additional years, then transfers it to off-site storage.  Once the freeze is lifted, 
these records can be destroyed when 5 years old. 
 
6. A/B MACs (A) and (HHH) and A/B MAC (B) or DME MAC Administrative Budget 
Estimate and Cost Report Form (FROZEN - DO NOT DESTROY) 
 
These files consist of all uses of the Administrative Cost and Budget Report, CMS-1523 for A/B 
MAC (B) or DME MAC and CMS-1524 for A/B MACs (A) or (HHH).  This form is a multi-use 
document and issued for budget and cost reporting activities. 
 
Specific uses are: 
 
a. Budget request, supplemental budget request, notice of budget approval, interim 
expenditure report. 
 
Disposition:  Once the freeze is lifted, destroy after a total retention of 3 years after HHS 
audit and final settlement. 
 
b. Supplemental Budget Request 
 
Disposition:  Once the freeze is lifted, destroy after a total retention of 3 years after HHS 
audit and final settlement. 
  c. Notice of Budget Approval.  The MACs certified funding authority for the fiscal year.  
Include all supporting schedules, correspondence and justification. 
 
Disposition:  Once the freeze is lifted, destroy after a total retention of 3 years after HHS 
audit and final settlement. 
 
d. Interim Expenditure Report.  Cumulative fiscal year to date expenditures incurred by 
the MAC.  Include all supporting schedules, correspondence and justifications. 
 
Disposition:  Once the freeze is lifted, destroy after a total retention of 3 years after HHS 
audit and final settlement. 
 
e. 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, correspondence, HHS or GAO audit reports on administrative cost 
and benefits payments. 
 
Disposition:  Once the freeze is lifted, destroy after a total retention of 6 years and 3 
months after HHS audit and final settlement. 
 
7. MAC Letter of Credit Files (FROZEN - DO NOT DESTROY) 
 
These records are authorizations to a Federal Reserve Bank to disburse funds to designated 
MACs banks on behalf of CMS upon presentation of request for funds for collection through the 
Federal Reserve System.  Included are Standard Form 1193, Letter of Credit or its equivalent, 
and amending letters. 
 
Disposition:  Once the freeze is lifted, destroy after a total retention of 6 years and 3 months after 
the year in which the letters of credit are cancelled. 
 
8. A/B MAC (A) or (HHH) Payment Vouchers and Transmittal Files (FROZEN - DO NOT 
DESTROY) 
 
These consist of Form TFS-218, Request for Funds, and similar documents prepared by the A/B 
MAC (A) or (HHH)s servicing bank to obtain Federal funds for benefits paid in administering 
medical insurance programs.  Also included is Form CMS-1521, Payment Voucher on Letter of 
Credit, a transmittal that forwards information on request for funds to CMS and shows the 
purpose for which funds were drawn, i.e., hospital insurance benefits, supplementary medical 
insurance benefits, and total amount of payment vouchers. 
 
Disposition:  Once the freeze is lifted, destroy after a total retention of 6 years and 3 months or 
after HHS audit and final settlement, whichever is later. 
 
9. A/B MAC or DME MAC Payment Vouchers and Transmittal Files (FROZEN - DO 
NOT DESTROY) 
 
These files consist of form TSF-5805, Request for Funds, and similar documents prepared by the 
A/B MAC (B) or DME MACs servicing bank to obtain Federal funds for benefits paid in 
administering medical insurance benefit programs.  Also included is Form CMS-1521, Payment  Voucher on Letter of Credit Transmittal, a transmittal that forwards information on request for 
funds to CMS and shows the purpose for which funds were drawn, i.e., SMI benefits and total 
amount of payment vouchers. 
 
Disposition:  Once the freeze is lifted, destroy after a total retention of 6 years and 3 months or 
HHS audit and final settlement, whichever is later. 
 
10. A/BMAC (A) or (HHH) Monthly Financial Report Files 
 
These are reports submitted monthly to provide CMS with the basic data to reconcile CMS's 
accounts with those that contractors maintain.  Included are Form CMS-1522, Monthly 
Intermediary Financial Report and attachments. 
 
Disposition:  Destroy after HHS audit and final settlement. 
 
11. A/B MAC (B) or DME MAC Performance Report Files 
 
These consist of Forms CMS-1565, Health Insurance for the Aged Program Carrier Performance 
Reports, and equivalent documents prepared monthly summarizing each A/B MAC (B) or DME 
MACs performance in processing claims.  The information provides management information 
needed for budgeting, financing, work planning, performance evaluation, and identifying 
operating problems. 
 
Disposition:  Destroy after 3 years. 
 
12. Ambulance Supplier Certification Files 
 
These consist of certifications of suppliers of ambulance services. 
 
Disposition:  Destroy 1 year from the end of the year when certification requirements are no 
longer met. 
 
13. Requests for Assistance from District Offices (DOs) (FROZEN - DO NOT DESTROY) 
 
These consist of correspondence and forms submitted to the DO for development of additional 
information or documents relating to a Medicare claim, e.g., incorrect name or Medicare 
beneficiary identifier and similar errors that prevent the processing of a claim. 
 
Disposition:  Once the freeze is lifted, dispose of in accordance with instructions for claims 
records. 
 
14. A/B MAC (A) or (HHH) Workload Reports Files 
 
These consist of monthly statistical reports on the status of A/B MAC (A) or (HHH) workloads 
used by CMS to identify basic management data needed for budgeting, financing, work planning, 
and progress evaluation.  Included is Form CMS-1566, Health Insurance for the Aged Program 
FI Workload Report, or equivalent documents. 
 
Disposition:  Destroy after 3 years.   
15. Overpayment and Duplicate Charge Detection Activity Report Files - A/B MAC (B) or 
DME MAC Report 
 
These consist of quarterly reports summarizing overpayment and duplicate charge detection 
activity.  They are used to tabulate data on the number of cases in which overpayments are 
recovered, the total dollar amount of money overpaid, causes of overpayments, number of 
duplicated charges detected, and similar information. 
 
Disposition:  Destroy after 3 years. 
 
16. Medicare Beneficiary Correspondence Files (FROZEN - DO NOT DESTROY) 
These accumulate as a result of inquiries and complaints received by CO, RO, and contractors 
and do not include any correspondence that is related to a claim file. 
 
Disposition:  Destroy 3 months after the date of the response to the correspondence. If a response 
is not required, the contractor destroys the material 3 months after the date of the 
correspondence. 
 
Where the material documents a specific claim, appeal, or similar case, the contractor follows the 
instructions for claims records. 
 
17. MAC Contract Files 
 
These consist of agreements entered into with MACs by the Secretary under the provisions of 
1816 and 1842 of the Act by which MACs agree to perform certain functions in administering 
the Hospital Insurance and Supplementary Medical Insurance programs.  As such, they provide 
basic documentation of the manner in which these programs are implemented.  Included are 
modifications and amendments. 
 
Disposition:  Destroy 3 years after supersession or termination, as applicable. 
 
18. MAC Subcontract Files 
 
These consist of copies of MAC agreements with subcontractors regarding performance of an 
audit of providers' costs A/B MAC (A) or (HHH), leases for building space, equipment, and 
consulting and other services.  Included are CMS approvals, amendments, and similar papers. 
 
Disposition:  Destroy 3 years after termination of agreement. 
 
19. Contract Performance Review Visit Files 
 
These consist of documents relating to scheduled or special visits to Medicare contractors to 
review your Medicare operations, to determine the degree of adherence to established policy and 
adequacy of service to the public, and to verify the accuracy of reporting.  Included are reports of 
staff visits, follow-up reports, communications concerning improvements in operations, and any 
other related documents. 
  Disposition:  Destroy 4 years after the close of the calendar year in which action on the review is 
completed. 
 
20. MAC Computer Printout Records (FROZEN - DO NOT DESTROY) 
 
These consist of computer printouts used in processing, paying, and controlling Medicare claims. 
 
 a. Pending and process listing, payment listing, duplicate check control, master file update 
control, and profiles of physicians and other suppliers of services. 
 
Disposition:  Once the freeze is lifted, destroy 4 years after the close of the calendar year in 
which payment was made. 
 
  b. Check listing and bank reconciliation. 
 
Disposition:  Once the freeze is lifted, destroy 6 years after the close of the calendar year in 
which paid or voided. 
 
 c. CWF inquiry or response listings, transaction listing, activity listings, posting exceptions, 
analysis of posting errors, claims inventory control, edit input transactions, and aging of 
open claims. 
 
Disposition:  Once the freeze is lifted, destroy 3 years after processing.  (Contractors with 
the capability of electronically retaining the CWF data may destroy the paper copies after 
the tapes have been verified.) 
 
21. A/B MAC (A) or (HHH) Cost Report Files (FROZEN - DO NOT DESTROY) 
 
These consist of cost reports submitted by providers to A/B MACs (A) or (HHH) for 
determining Medicare reimbursable costs in accordance with regulations and the principles of 
reimbursement.  The cost report file includes: (a) a copy of the original cost report form as filed 
by the provider; (b) copies of all decisions made by field auditors, including those subsequently 
reversed by senior auditors; (c) a copy of the Audit Adjustment Report; (d) a copy of revised cost 
report schedules (or a revised cost report); (e) a copy of the notice of program reimbursement; (f) 
a copy of the audit report when prepared by the A/B MAC (A) or (HHH) staff accountants and 
the supporting audit working papers. 
 
Disposition:  The A/B MAC (A) or (HHH) maintains the cost report on premises for 3 years after 
the Notice of Amount of Medicare Program Reimbursement has been issued to the provider, and 
then transfers cost report to inactive storage.  Once the freeze is lifted, destroy the cost report 
files 5 years after receipt. 
 
(Exception: A cost report file that is the subject of an appeal, litigation, or any other 
administrative proceedings, e.g., collection of outstanding overpayments or bankruptcies is not 
sent to inactive storage until the case has been settled or closed and all the review and appeal 
procedures have been exhausted.) 
 
22. MAC Closing Agreements 
  These files contain the accepted final settlement for all MAC costs of administration and consist 
of the closing agreement, appendix, and schedules of balances due the MAC or Secretary. 
 
Disposition:  The MAC cuts off files at the end of the fiscal year.  It holds the file in office 1 year 
after HHS audit and final settlement then transfers to inactive storage.  Destroy these 10 years 
after HHS audit and final settlement. 
 
23. Medicare Data Match Files (FROZEN - DO NOT DESTROY) 
 
Questionnaires, case files, employer records and data match records. 
 
Disposition:  Cutoff files at the end of the calendar month and transfer to an offsite storage 
facility.  Once the freeze is lifted, destroy 6 years and 3 months after cutoff. 
 
24. Initial Enrollment Questionnaire (FROZEN - DO NOT DESTROY) 
 
Questionnaires sent to newly enrolled Medicare beneficiaries to obtain information on whether 
the individual is covered under a primary insurance plan. 
 
Disposition:  Once the freeze is lifted, destroy/delete when 5 years old. 
 
25. Provider Statistical and Reimbursement Reports (PS&RR) - (FROZEN - DO NOT 
DESTROY) 
 
These files consist of EDP printouts or microforms showing summaries of payments to hospitals, 
skilled nursing facilities, home health agencies, and other providers of service.  They are used to 
effect cost settlements between the A/B MACs (A) or (HHH) and the providers for program 
validation purposes and to determine accuracy of cost reports.  These reports contain Part A and 
Part B inpatient and outpatient information, inpatient statistics, total bills, covered costs, and 
other related data. 
 
Disposition:  Once the freeze is lifted, destroy 5 years after completion of audit and/or settlement 
process for provider cost report for corresponding fiscal year. 
 
26. A/B MAC (B) or DME MAC Claims Processing File 
 
Consists of documents relating to Part B A/B MAC (B) or DME MAC performance.  Submitted 
on a weekly basis electronically to CMSs data center. 
 
Disposition: Destroy after 6 months. 
 
30.40 - Retention of Claims File Materials 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
After the claims determination payment action and posting to CMS records is completed, the 
bills and related materials are accumulated in file segments and held before transfer to an 
approved offsite storage facility (see 30.40.2).  Claims records having current value and 
continuing reference, or claims records otherwise flagged to indicate pending action, are retained 
as long as the A/B MAC (B) or DME MAC finds necessary.   
30.40.1 - Segment File Accumulation Period 
(Rev. 124, Issued: 05-17-19, Effective: 06-18-19, Implementation: 06-18-19 
 
The term Medicare beneficiary identifier (Mbi) is a general term describing a beneficiary's 
Medicare identification number. For purposes of this manual, Medicare beneficiary identifier 
references both the Health Insurance Claim Number (HICN) and the Medicare Beneficiary 
Identifier (MBI) during the new Medicare card transition period and after for certain business 
areas that will continue to use the HICN as part of their processes. 
 
In order to facilitate the transfer of material to an approved offsite storage facility, MACs 
maintain the permanent claims records files in accumulation period segments, based on the 
starting date of initial payment or denial.  Each contractor may select an accumulation period 
segment of from 6 months to 2 years in length after such starting date.  The contractor may also 
adopt one period of time on an ongoing basis, but a different period for the initial segment. 
 
Contractors who have been authorized to microfilm/image claims records may be authorized to 
shorten the segment file accumulation period.  (See 30.50.) 
 
After a file segment is closed, the contractor retains the records contained in that segment until 
time to transfer them to an approved storage facility.  (See 30.40.2 and 30.40.3 for definition 
of retention periods.) 
 
EXCEPTION:  Contractors who maintain total history files by individual Medicare beneficiary 
identifier, name, or other sequence, may wish to operate under some procedure 
other than by a file segment accumulation period. 
 
Such alternative procedures may be used provided purging techniques to withdraw inactive 
records are established which meet one of the following requirements: 
 
1.  They avoid costly and time consuming manual selection of material to be purged from each 
folder. 
 
2.  Separators are used for each year's (or other period's) material within the history folder to 
facilitate rapid selection. 
 
3.  The capability exists (e.g., computer prepared lists) to identify inactive cases in which no 
action has been taken for 12 months or more for selection as purged segments to be transferred to 
an approved storage facility when such a purge becomes necessary. 
 
4.  Periods for purging and transfer are carefully selected by studying rates of reference to claims 
materials in order to select a realistic inactive period to avoid unnecessary recall from the storage 
facility. 
 
Although contractors who follow a purging procedure need not establish a standard retention 
period, the establishment of one of these requirements provides them with the potential of 
transferring inactive files to a storage facility if such a transfer should become desirable.  When 
such a purge is begun, the contractor should make no transfer to the storage facility until the 
entire purging operation for the period is completed.  30.40.2 - Standard Retention Periods - Microfilmed Claims 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
Contractors keep each permanent claims records file segment for a period of not less than 6 
months or more than 1 1/2 years after the segment has been closed.  The contractor bases the 
selection of a retention period on its experience with the rate and frequency of reference and 
other criteria. It also should avoid too early transfer to the storage facility, which could result in 
volume recalls and delays.  The contractor bases the exact length of the retention period on its 
needs and on the arrangements worked out with the storage facility. 
 
The following examples of segment accumulation and retention periods demonstrate some of the 
ways in which these periods can vary. 
 
EXAMPLES:  Segment Files 
 
Accumulation Period  Retention Period  Transfer 
a.  6 months     
  7/1/05 - 12/31/05  6 months  7/1/06 
  1/1/06 - 6/30/06  6 months  1/1/07 
  1/1/06 - 6/30/06  12 months  7/1/06 
  1/1/06 - 6/30/06  18 months  1/1/07 
b.  9 months     
  7/1/05 - 3/31/06  6 months  10/1/06 
  7/1/05 - 3/31/06   12 months  4/1/07 
  7/1/05 - 3/31/06  18 months  10/1/07 
c.  12 months     
  1/1/05 - 12/31/05  6 months  7/1/06 
  1/1/05 - 12/31/05  12 months  1/1/07 
  1/1/05 - 12/31/05  18 months  7/1/07 
d.  18 months     
  1/1/05 - 6/30/07  6 months  1/1/08 
  1/1/05 - 6/30/07  12 months  7/1/08 
  1/1/05 - 6/30/07  18 months  1/1/09  Accumulation Period  Retention Period  Transfer 
e.  2 years     
  7/1/05 - 6/30/07  6 months  1/1/08 
  7/1/05 - 6/30/07  12 months  7/1/07 
  7/1/05 - 6/30/07  18 months  1/1/09 
 
30.40.3 - Retention Period - Microfilmed Material 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
MACs who have been authorized to microfilm claims records (see 50ff) may be permitted to 
transfer an accumulation of the original source documents to an approved offsite storage facility, 
after retaining for a shorter period than is outlined in 30.40 - 30.40.2. 
 
Accumulation Period  Retention Period  Transfer 
a.  1/1/06 - 1/31/06  1 month  3/1/06 
b.  6/1/06 - 6/30/06  1 month  8/1/06 
 
30.50 - Microfilming of Files Material 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
Some MACs have been authorized to microfilm claims records and other files material; e.g., 
computer printouts, cancelled checks, financial records.  Due to the document freeze, these 
contractors are not authorized to destroy original source documents but are permitted to transfer 
an accumulation of these documents to an offsite storage facility after microfilming and 
verification of the quality and completeness of the film.  (See 30.30.2, item 3, concerning 
destruction the hard copy Medicare Summary Notices after microfilming.)  The accumulation 
period may be daily, weekly, or monthly, depending on volume.  Generally, contractors should 
not make shipments of less than three cartons.  They coordinate transfer procedures with the 
storage facility. 
 
In 30.90, Exhibits 6-12 contain various sample forms to be used by contractors when 
microfilming files material.  These forms are not supplied by CMS.  Reproduction of the forms is 
the responsibility of the contractor. 
 
30.50.1 - Microfilming Procedures 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
A - General 
 
The contractor must authenticate each roll of film containing reproductions of Medicare claims 
records by including certificates of authenticity at the start and at the end of the filmed 
documents. (Material other than claims records need not be authenticated.)  The contractor  produces these certificates and target cards as needed, using the language contained in the 
examples in 80, Exhibits 6-12.  The camera operator completes a report for each roll that is 
microfilmed.  See Exhibit 12, for an example of a roll report.  The contractor films claims 
records without attachments (e.g., coding sheets) overlaying data on the record.  If data on the 
attachment is needed for reference purpose, the contractor films it separately. 
 
To ensure that the camera is working efficiently when files material is being microfilmed, the 
contractor films a microcopy resolution test chart on the first roll in the morning and the first roll 
in the afternoon.  It gives these rolls priority processing so that any camera malfunction is 
discovered as soon as possible. Exhibit 11 provides an example of a resolution test chart that 
cannot be used for actual tests.  Usable charts are available from microfilm suppliers. 
 
B - Normal Filming 
 
The contractor films the start certificate (see Exhibit 5) after any target (or flash) cards that 
identify or index the documents on the film and before the records are filmed.  It files the end 
certificate (Exhibit 6) after the last document and before any end target card.  It retains 
documents in the order they were filmed for ease in reviewing the processed microfilm. 
 
The following is an example of normal filming sequence: 
 
OUT  LEADER  ROLL    FILING  START  TEST* 
SEQUENCE  CERTIFICATION 
START  <ABOUT- NUMBER  TITLE  CARD  CHART  
2 FEET  OF 
   OF  CARD  CARD 
AUTHENTICITY 
FILM  CARD 
 
\          LAST   \ 
/        LAST  CERTIFICATE   / 
\  DOCUMENT  DOCUMENT  DOCUMENT  DOCUMENT  OF  \ 
AUTHENTICITY 
/  CARD  / 
\  \ 
 
/        *Filmed Twice Each Day  \ 
\  END          TRAILER ABOUT  END OF FILM  / 
/  CARD  2 FEET  /  \ 
\    /  \ 
 
C - Corrections 
 
If the camera operator notices that a document has been incorrectly filmed due to being twisted, 
folded, or torn, photograph a correction card (see Exhibit 7) right after the incorrect document. 
 
The following is an example of correction filming sequence: 
 
\             
/  DOCUMENT  DOCUMENT  CORRECTION  DOCUMENT  DOCUMENT  / 
\  (TORN)  CARD  (REPAIRED)  \ 
/  / 
\  \ 
 
D - Filming Retakes and Additions 
 
When the processed microfilm roll is reviewed, some documents may be illegible or incorrectly 
photographed.  Other documents may have been out of file or omitted at the time of the original 
microfilming.  The contractor will re-photograph these documents and splice onto the front of 
the completed microfilm roll.  If splicing is not practical, it will maintain the retakes and 
additions as a separate microfilm roll.  It will photograph a start of retake or addition card 
(Exhibit 8) immediately before the documents to be rephotographed or added.  Photograph an 
end of retake or addition certificate (Exhibit 9) immediately after the last document to be 
rephotographed.  The following is an example of retake or addition filming sequence: 
 
\            \ 
/  START RE- DOCUMENT  DOCUMENT  DOCUMENT  END OF  / 
TAKE OR  ADDITION OR 
\  ADDITION  RETAKE  \ 
CARD  CERTIFICATE 
/  / 
\  \ 
 
30.50.2 - Microfilming Index Label 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
Affix an index label to each contents of the roll microfilm and provide reference markers.  It lists 
the normal filming and the retakes and additions. 
  Below is an example of an index label: 
 
Title:        Roll No. 
CMS-1453 
    CONTENTS INDEX 
    Index Point 1 
CMS-1453    Control Number 
       00400     Through   00450 
    Index Point 2 
CMS-1453    Control Number 
       00451      Through   00499 
    Index Point 3 
Retakes  00427, 00451, 00478 
    Index Point 4 
Additions  00429, 00446, 00463 
END OF ROLL 
End of Roll 
 
30.50.3 - Retention and Destruction of Microfilm 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
A - Master Microfilm 
 
After producing the number of copies of the microfilm required for reference purposes, the 
contractor retains the master microfilm as a security file.  It stores it at an offsite location so that 
copies may be made in the event the reference copies are destroyed.  It disposes of the master 
microfilm at the time the storage facility disposes of the hardcopy contained on the film.  (See 
30.30 for records disposition instructions.) 
 
(The contractor need not maintain a master microfilm security file of records such as computer 
printouts when complete computerized backup data is retained.  It disposes of the master 
microfilm when there is no longer a need to produce reference copies of the microfilm.) 
 
B - Copies of Microfilm 
  The contractor retains one copy of the microfilm as a reference copy to be kept on site for use 
when needed.  It disposes of this copy with the master microfilm.  (See subsection A above.) 
 
The contractor may dispose of any other reference copies of the microfilm 2 years after the end 
of the calendar year in which the documents were filmed.  These copies may be retained for a 
longer period if they are needed for reference purposes but not longer than the master microfilm. 
 
C - Destruction of Microfilm 
 
The contractor should destroy microfilm by shredding as this method provides the most complete 
destruction of the data on the film.  Other methods of destroying film, e.g., exposure to extreme 
heat or boiling, do not eradicate the data as completely or efficiently.  Shredders exist that can 
destroy both film and reels.  The contractor should retain cartridges or magazines which 
contained the microfilm for reuse because of the high cost of replacement. 
 
If a contractor does not have a shredder and purchase of a shredder is not cost justified, it should 
check local sources such as microfilm equipment vendors, microfilm service bureaus, banks, and 
insurance companies for a shredder that it can use to destroy its film.  If a shredder cannot be 
located, the contractor should contact its regional office for assistance. 
 
30.60 - Annual Report of Medicare Records 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
The Centers for Medicare & Medicaid Services (CMS) conducts a reporting of total records on 
hand in current file rooms, offices, and offsite storage facilities.  Since Medicare claims records 
and related records created and maintained by you must be included, you must prepare an 
Annual Report of Medicare Records (See Exhibit 13). 
 
Each contractor shall prepare this report every year as of September 15, regardless of your fiscal 
year ending date, and mail one copy to reach the address shown below no later than September 
30: 
Centers for Medicare & Medicaid Services 
Records Officer, OSORA/IRMG 
Mail Stop, SL-12-16 
7500 Security Boulevard 
Baltimore, MD  21244-1850 
 
30.70 - Disposition of Non-Claims Materials 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
Non-claims materials, as defined in 30.10.1B, may be disposed of by the contractor.  Retained 
CMS bill copies (where records were submitted on tape) may be destroyed. 
 
In disposing of this material, the contractor must: 
 
  Ensure the confidentiality of information regarding a particular beneficiary, provider, 
physician, or supplier by protective shredding, mutilation, or contractual provisions with 
the subcontractor regarding similar protective measures. 
    Provide for offsetting expenditures with salvage value received when contractual 
relationships have been established with a local contractor for the sale of non-claims 
materials for its salvage value.  In such cases, the contractor records the salvage value 
received, and offsets the initial expense of purchasing such materials by such value 
received. 
 
30.80 - Standards for All Records Storage Facilities 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
A facility that is used to store Federal records, must meet the minimum structural, 
environmental, property and life safety standards as outlined in 36 CFR 1228.228-Facility 
Requirements http://www.access.gpo.gov/nara/cfr/waisidx_05/36cfr1228_05.html by October 1, 
2009.  You must submit a Facility Standards for Record Storage Facilities Inspection Checklist 
(see Exhibit 14) for all storage facilities used to house CMS records to the CMS Records Officer. 
 
The facility must be constructed with non-combustible materials and building elements, 
including walls, columns and floors.  You may request a waiver of this requirement from the 
National Archives and Records Administration through CMS for an existing records facility with 
combustible building elements to continue to operate until October 1, 2009.  Your request must 
provide documentation that the facility has a fire suppression system specifically designed to 
mitigate this hazard and that the system meets the requirements in 36 CFR 1228.230--Fire Safety 
Requirements http://www.access.gpo.gov/nara/cfr/waisidx_05/36cfr1228_05.html.  Requests for 
waivers must be submitted to your CMS Regional Office contact who will forward to the CMS 
Records Officer for final approval by the National Archives and Records Administration. 
 
30.90 - Exhibits 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
Exhibit 1.  Preprinted Container Label 
Exhibit 2.  Minimum Label Data Required for Unlabeled Boxes  
Exhibit 3.  Records Transmittal and Receipt - Standard Form 135 
Exhibit 4.  Reference Request - Federal Records Center - Optional Form 11 
Exhibit 5.  Certificate of Authenticity - Start 
Exhibit 6.  Certificate of Authenticity - End 
Exhibit 7.  Correction Card 
Exhibit 8.  Start of Retake or Addition Certificate 
Exhibit 9.  Retake or Addition Certification 
Exhibit 10.  Resolution Test Chart 
Exhibit 11.  Witness Disposal Certification (Sample)  Exhibit 12.  Roll Report 
Exhibit 13  Report of Medicare Records 
Exhibit 14  Inspection Checklist -- Standards for Record Storage Facilities  Exhibit 1 - Preprinted Container Label 
(Rev.124, Issued: 05-17-19, Effective: 06-18-19, Implementation: 06-18-19 
 
ACCESSION NO.          CARTON NO.    of 
AGENCY      MAJOR SUBDIVISION 
 
DESCRIPTION OF RECORDS (BRIEF) 
 
 
Instructions for Completing Label 
 
Accession No. - Control number you assign to each shipment of records. 
 
Carton No. - Show the box number and also the total number of boxes in the same shipment, 
e.g., 5 of 60. 
 
Agency - Enter CMS 
 
Major Subdivision - Enter the name of the MAC in this block. 
 
Description of Records - Enter Part A A/B MAC (A) or (HHH) or Part B A/B MAC (B) or 
DME MAC - Medicare bills and related claims records received, processed and paid (including 
dates), or Part A A/B MAC (A) or (HHH) - Medicare Fiscal Records, canceled checks and 
related records (including dates). 
 
Also, for each box, show the inclusive claims numbers, dates, etc., depending on arrangement of 
records. 
 
Exhibit 2 - Minimum Label Data Required for Unlabeled Boxes 
(Rev. 124, Issued: 05-17-19, Effective: 06-18-19, Implementation: 06-18-19 
 
For boxes not having a preprinted label (see Exhibit 1 above), enter the label as shown: 
 
CARTON   _____   OF  ______  CARTONS 
  CMS 
  MAC NAME 
  CITY, STATE 
  MAC - PAID MEDICARE BILLS    DATE TO DATE 
  (086-12-8462A--093-14-2362T) 
 
Instructions For Labeling Boxes 
 
Use broad-point felt tip marker to facilitate shelf reference. 
 
Minimum Label Data 
 
Accession Number - Control number assigned to each shipment of records. 
 
Carton No. - Show the box number and also total boxes in the shipment, e.g., 5 of 60. 
 
Agency - Show "CMS." 
 
Office - Show the name of MAC with city and State address. 
 
Description of Records - For Medicare bills and related records, show:  "MAC name - Paid 
Medicare Bills (inclusive dates)."  For fiscal records, canceled checks, and related records, show: 
" MAC - Medicare Fiscal Records (inclusive dates)." 
 
First and Last Entry in Box - Show the inclusive claim number, terminal digit numbers, check 
numbers, or other designated key numbers. 
  Exhibit 3 - Records Transmittal and Receipt - Standard Form 135 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
Click on the link below then scroll down and click on Records Transmittal and Receipt Form - 
SF135. 
 
http://www.archives.gov/records_center_program/forms/sf_135_intro.html 
 
Exhibit 4 - Reference Request - Federal Records Center - Optional Form 11 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
Click on the link below to access Optional Form 11 
 
http://www.gsa.gov/forms 
 
Exhibit 5 - Certificate of Authenticity - START 
(Rev. 124, Issued: 05-17-19, Effective: 06-18-19, Implementation: 06-18-19 
 
The term Medicare beneficiary identifier (Mbi) is a general term describing a beneficiary's 
Medicare identification number. For purposes of this manual, Medicare beneficiary identifier 
references both the Health Insurance Claim Number (HICN) and the Medicare Beneficiary 
Identifier (MBI) during the new Medicare card transition period and after for certain business 
areas that will continue to use the HICN as part of their processes. 
 
  CONTRACTOR NAME AND ADDRESS 
 
  CERTIFICATE OF AUTHENTICITY 
 
  START 
 
THIS IS TO CERTIFY THAT THE MICROPHOTOGRAPHIC IMAGES APPEARING ON 
THIS ROLL OF MICROFILM: 
 
STARTING WITH (e.g., control number, Medicare beneficiary identifier) 
 
ARE ACCURATE REPRODUCTIONS OF THE RECORDS OF: 
 
AND WERE MICROFILMED IN THE REGULAR COURSE OF BUSINESS PURSUANT TO 
ESTABLISHED ROUTINE COMPANY POLICY FOR SYSTEMS UTILIZATION AND OR 
FOR THE MAINTENANCE AND PRESERVATION OF SUCH RECORDS THROUGH THE 
STORAGE OF SUCH MICROFILMS IN PROTECTED LOCATIONS. 
 
IT IS FURTHER CERTIFIED THAT THE PHOTOGRAPHIC PROCESSES USED FOR 
MICROFILMING OF THE ABOVE RECORDS WERE ACCOMPLISHED IN A MANNER 
AND ON MICROFILM THAT MEETS THE RECOMMENDED REQUIREMENTS OF THE 
NATIONAL BUREAU OF STANDARDS FOR PERMANENT MICROPHOTOGRAPHIC 
REPRODUCTIONS. 
 
Date Microfilmed          Camera Operator   
Location            Authorized Signature 
 
Exhibit 6 - Certificate of Authenticity - END 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
  CONTRACTOR NAME AND ADDRESS 
 
  CERTIFICATE OF AUTHENTICITY 
 
  END 
 
THIS IS TO CERTIFY THAT THE MICROPHOTOGRAPHIC IMAGES APPEARING ON 
THIS ROLL OF MICROFILM: 
 
ENDING WITH 
 
ARE ACCURATE REPRODUCTIONS OF THE RECORDS OF: 
 
AND WERE MICROFILMED IN THE REGULAR COURSE OF BUSINESS PURSUANT TO 
ESTABLISHED ROUTINE COMPANY POLICY FOR SYSTEMS UTILIZATION AND OR 
FOR THE MAINTENANCE AND PRESERVATION OF SUCH RECORDS THROUGH THE 
STORAGE OF SUCH MICROFILMS IN PROTECTED LOCATIONS. 
 
IT IS FURTHER CERTIFIED THAT THE PHOTOGRAPHIC PROCESSES USED FOR 
MICROFILMING OF THE ABOVE RECORDS WERE ACCOMPLISHED IN A MANNER 
AND ON MICROFILM THAT MEETS THE RECOMMENDED REQUIREMENTS OF THE 
NATIONAL BUREAU OF STANDARDS FOR PERMANENT MICROPHOTOGRAPHIC 
REPRODUCTIONS. 
 
Date Microfilmed            Camera Operator 
 
Location              Authorized Signature 
 
Exhibit 7 - Correction Card 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
CORRECTION CARD 
 
CORRECTION 
THIS DOCUMENT 
HAS BEEN REPHOTOGRAPHED 
TO ASSURE LEGIBILITY 
 
  Exhibit 8 - Start of Retake or Addition Certificate 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
RETAKE OR ADDITION CARD 
START OF RETAKE OR ADDITION 
 
The images appearing between this point and the "End of Retake or Addition" are true 
copies of records, which were missing or provide unsatisfactory on inspection of the 
original microfilm reel. 
 
For a description of rephotographed material, see operator's "Retake or Addition 
Certificate" at the end of this section. 
 
 
Exhibit 9 - Retake or Addition Certificate 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
CONTRACTOR NAME AND ADDRESS 
 
CERTIFICATE OF AUTHENTICITY 
 
RETAKES OR ADDITIONS 
 
THIS IS TO CERTIFY THAT THE MICROPHOTOGRAPHIC IMAGES APPEARING ON 
THIS ROLL OF MICROFILM: 
ENDING WITH 
 
ARE ACCURATE REPRODUCTIONS OF THE RECORDS OF: 
 
AND WERE MICROFILMED IN THE REGULAR COURSE OF BUSINESS PURSUANT TO 
ESTABLISHED ROUTINE COMPANY POLICY FOR SYSTEMS UTILIZATION AND OR 
FOR THE MAINTENANCE AND PRESERVATION OF SUCH RECORDS THROUGH THE 
STORAGE OF SUCH MICROFILMS IN PROTECTED LOCATIONS. 
 
IT IS FURTHER CERTIFIED THAT THE PHOTOGRAPHIC PROCESSES USED FOR 
MICROFILMING OF THE ABOVE RECORDS WERE ACCOMPLISHED IN A MANNER 
AND ON MICROFILM THAT MEETS THE RECOMMENDED REQUIREMENTS OF THE 
NATIONAL BUREAU OF STANDARDS FOR PERMANENT MICROPHOTOGRAPHIC 
REPRODUCTIONS. 
 
Date Microfilmed          Camera Operator 
 
Location            Authorized Signature 
  Exhibit 10 - Resolution Test Chart 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
The resolution test chart can also be viewed at the following link: 
 
http://www.efg2.com/Lab/ImageProcessing/TestTargets/#Microcopy 
 
 
 
  Exhibit 11 - Witness Disposal Certification (Sample) 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
WITNESSED DISPOSAL CERTIFICATION 
Disposal Date:   _____________________ 
Medicare Contractor: ________________________________________ 
Address:      ________________________________________ 
        ________________________________________ 
Disposal Location:  ________________________________________ 
_____________________________________________________________ 
 
Volume by Cubic Feet (e.g., number of boxes):  ____________________ 
Description & Year(s) of Records Destroyed: 
_____________________________________________________________ 
_____________________________________________________________ 
_____________________________________________________________ 
_____________________________________________________________ 
I certify that I witnessed the proper destruction of CMS Medicare records approved for disposal 
on the date and location named in this document. 
Print Name:  __________________________________ 
Title:      __________________________________ 
Signature:    __________________________________ 
Date:      ________________  Exhibit 12 - Roll Report 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
ROLL REPORT       
THEIR ROLL   
NO.  
 
 
                   
AGENCY    OUR ORDER   
 
NAME  NUMBER 
 
                       
CAMERA NO.   LIGHT LEVEL   IRIS   REDUCTION  
 
     
FILMING TIME  
                                   
LUNCH    BREAK   PREP   WAITING   SET-UP   TRAVEL  
       
TIME   TIME  TIME TIME TIME TIME
PROCESSING DEPARTMENT 
                             
DATE PROC.   DEV. TIME   CHEM. TEMP   REMARKS   PROCESSOR  
INSPECTION DEPARTMENT 
APPROVED   INSPEC.   INSPECTORS 
                             
RESHOOTS   FOOTAGE   TIME   INTIALS   DENSITY  
 
RESHOOTS WILL BE FOUND ON       
THIS ROLL FOR ROLL NUMBERS 
 
REMARKS      
  OPERATORS INITIALS      
  Exhibit 13  Report of Medicare Records 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
ANNUAL REPORT OF MEDICARE RECORDS 
   
Name & Address of Medicare 
Contractor 
 
 
   
Name, Title and Phone # of the 
Person Submitting the Report  
 
 
Type of Medicare Contractor   
(Carrier/Intermediary/DMERC, etc.) 
 
       
  Current File  Offsite  Storage 
Room  Storage  Costs 
1. Total Records on Hand at the End of       
the Reporting Period  
  a. Magnetic Tape Included in Line 1       
  b. Microfilm Included in Line 1       
  c. CDs included in Line 1       
  d. Paper included in Line 1       
       
2. Records Transferred to Storage       
During Reporting Period (provide the 
number of boxes)    a. To Offsite Storage Included in Line      $ 
2 
  b. To Onsite Storage Included in Line      $ 
2 
TOTAL STORAGE COSTS (Add      $ 
2a+b) 
       
3. Total Records in Offsite Storage       
During the Contract Period 
 
 
For the purpose of this report, volume may be calculated according to the following table of 
cubic foot equivalents: 
 
1 record storage box..................1 cubic foot 
Letter-size filing cabinet.............112 cubic feet per drawer 
Legal-size filing cabinet..............2 cubic feet per drawer 
Magnetic Tape.........................1 cubic foot per 7 reels 
Microfilm...............................1 cubic foot per 108 rolls 
CDs......................................14 cubic foot per 12 case holder 
  Exhibit 14 - Inspection Checklist - Facility Standards for Records Storage 
Facilities 
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06) 
 
Facility Standards for Records Storage Facilities 
Inspection Checklist (Effective date of checklist September 2005) 
Agency:   
Facility:    
Common 
Name: 
Facility:  Street   
Address 
Facility:  City,   
State & Zip 
Facility  <<Typed name>> 
Director or 
Representative:  <<Typed Title>> 
  Comments explaining or disagreeing with inspection findings are attached. 

Inspector:  <<Typed name>>                                                      Date 
<<Typed Title>> 
Facility   
Description: 
 
 
 
 
 
 
 
  Compliance with 36 CFR 1228.228 Facility Requirements 
1228.228  Requirement  OK  No  Other 
paragraph: 
(a)  The facility must be constructed with non-combustible       
materials and building elements, including walls, columns, 
and floors. 
(a)  If the roof is constructed of combustible material it is       
protected by a properly installed and maintained wet-pipe 
exception 1  automatic sprinkler system. 
(a)  Existing records storage facility with combustible building       
elements has an approved waiver from NAS that allows 
exception 2  continued use until October 1, 2009 provided 
documentation has been submitted that indicates a fire-
suppression system designed to mitigate the risk is present. 
(b)  A facility with two or more stories must be designed or       
certified by a licensed fire protection engineer and 
civil/structural engineer to avoid catastrophic failure of the 
structure due to an uncontrolled fire on one of the 
intermediate levels. 
(c)  The building must be sited a minimum of five feet above       
and 100 feet from any 100 year flood plain areas, or be 
protected by an appropriate flood wall (see FEMA flood 
maps) 
(d)  The facility must be designed in accordance with national,       
regional, state or local building codes (whichever is most 
stringent) to provide protection from building collapse or 
failure of essential equipment from earthquake hazards, 
tornadoes, hurricanes, and other natural disasters. 
(e)  Roads, fire lanes, and parking areas must permit       
unrestricted access for emergency vehicles. 
(f)  A floor load limit must be established for the records       
storage area by a licensed structural engineer. ... The 
allowable load limit must be posted in a conspicuous place 
and must not be exceeded. 
(g)  The facility must ensure that the roof membrane does not       
permit water to penetrate the roof. (New buildings: effective 
9/28/2005; existing buildings: effective 10/1/2009)  1228.228  Requirement  OK  No  Other 
paragraph: 
(h)  Piping (with the exception of sprinkler piping and storm       
water roof drainage piping) must not be run through the 
records storage area unless supplemental measures ... are 
used to prevent water leaks .... (New buildings: effective 
9/28/2005; existing buildings: effective 10/1/2009) 
(i)(1)  All storage shelving must be designed and installed to       
provide seismic bracing that meets the requirements of the 
applicable state, regional, and local building code 
(whichever is most stringent). 
(i)(2)  Racking systems, steel shelving, or other open-shelf records       
storage equipment must be braced to prevent collapse under 
full load.  Each shelving unit must be industrial style 
shelving rated at least 50 lbs per cubic foot supported by the 
shelf. 
(i)(3)  Compact shelving, if used, must be designed to permit       
proper air circulation and fire protection ... 
(j)  The records storage area must be equipped with an anti-      
intrusion alarm system ... meeting the requirements of UL 
1076, Proprietary Burglar Alarm Units and Systems (level 
AA) .... The alarm system must be monitored in accordance 
with UL 611, Central Station Burglar Alarm Systems. 
(k)  The facility must comply with the requirements for a Level       
III facility. (Appendix A -- see separate checklist) 
(l)  Records contaminated by hazardous materials ... must be       
stored in separate areas having separate air handling 
systems from other records. 
(m)  The facility must have an Integrated Pest Management       
program. 
(n)  The following additional requirements apply only to new       
facilities: 
 
(n)(1)  (1) No mechanical equipment containing motors in excess       
of 1 HP within records storage areas (excluding material 
  handling and conveyance equipment that have operating 
thermal breakers on the motor). 
  1228.228  Requirement  OK  No  Other 
paragraph: 
(n)(2)  (2) No high-voltage electrical distribution equipment (i.e.,       
13.2kv or higher) in records storage areas. 
 
(n)(3)  (3) A redundant source of primary electrical service ...       
should be provided ... .  Manual switching between sources 
  of service is acceptable.  (See text in rule; applies to HVAC, 
fire and security alarms.) 
 
(n)(4)  (4) For new facilities that store permanent records:       
(n)(4)a  a. A facility storing permanent records must be kept under       
positive pressure. 
 
(n)(4)b  b. No intake louvers in loading dock areas, parking or other       
areas subject to vehicle traffic. 
 
(n)(4)c  c. Separate air supply and exhaust system for loading docks.        
 
Compliance with 36 CFR 1228.230 Fire Safety Requirements 
1228.230  Requirement  OK  No  Other 
paragraph: 
(a)  The fire detection and protection system must be designed       
or reviewed by a licensed fire protection engineer.  
Review requires submission of a report under the seal of a 
licensed fire protection engineer; see rule text for 
minimum requirements. 
(b)(1)  All walls separating records storage areas from each other       
and from storage areas within the building must be 3-hour 
fire resistant. 
(b)(2)  The quantity of Federal records stored in a single fire       
compartment shall not exceed 250,000 cubic feet. 
(c)(1)  For existing records storage facilities, at least 1-hour rated       
fire barrier walls must be provided between the records 
storage area(s) and other auxiliary spaces.  1228.230  Requirement  OK  No  Other 
paragraph: 
(c)(2)(a)  For new records storage facility, 2-hour-rated fire barrier       
walls must be provided between the records storage 
area(s) and other auxiliary spaces. 
(c)(2)(b)  For new facilities, at least one exterior wall of each stack       
area must be designed with a maximum fire resistive 
rating of one-hour, or, if rated more than one-hour, there 
must be at least one knock-out panel in one exterior wall 
of each stack. 
(d)  Penetrations in the walls must not reduce the specified fire       
resistance ratings. 
(e)  The fire resistive rating of the roof must be a minimum of       
12 hour. 
(e)  Unrated roof is protected in accordance with NFPA 13.       
alternate 
(f)  Openings in fire barrier walls must be protected by self-      
closing or automatic Class A fire doors, or equivalent 
doors that maintain the same rating as the wall. 
(g)  Roof support structures that cross or penetrate fire barrier       
walls must be cut and independently supported on each 
side of the fire barrier wall. 
(h)  If fire barrier walls are erected with expansion joints, the       
joints must be protected to their full height. 
(i)  Building columns in records storage areas must be 1-hour       
fire resistant. 
(i)  Unrated columns are protected in accordance with NFPA       
13. 
alternate 
(j)(1)  Automatic roof vents for routine ventilation purposes must       
not be designed into new records storage facilities. 
(j)(2)  Automatic roof vents, designed solely to vent in the case       
of a fire, with a temperature rating of at least twice that of 
the sprinkler heads are acceptable.  1228.230  Requirement  OK  No  Other 
paragraph: 
(k)  Where lightweight steel roof or floor supporting members       
are present, they must be protected either by applying a 
10-minute fire resistive coating to the top chords of the 
joists, or by retrofitting the sprinkler system with large 
drop sprinkler heads.  (see rule text) 
(l)  Open flame (oil or gas) unit heaters or equipment, if used,       
must be installed or used in any records storage area in 
accordance with NFPA 54 and the UMC. 
(m)  For existing records storage facilities, boiler rooms or       
rooms containing equipment operating with a fuel supply 
... must be separated from records storage areas by a 2-
hour rated fire barrier wall with no openings directly from 
those rooms to the records storage area(s).  Such areas 
must be vented directly outside to a location where fumes 
will not be drawn back into the facility. 
(n)  For new records storage facilities, boiler rooms or rooms       
containing equipment operating with a fuel supply ... must 
be separated from records storage areas by a 4-hour rated 
fire barrier wall with no openings directly from those 
rooms to the records storage area(s).  Such areas must be 
vented directly outside to a location where fumes will not 
be drawn back into the facility. 
(o)  For new records storage facilities, fuel supply lines must       
not be installed in areas containing records, and must be 
separated from such areas with 4-hour-rated construction. 
(p)  Equipment rows running perpendicular to the wall must       
comply with NFPA 101 Life Safety Code, with respect to 
egress requirements. 
(q)(1)  No oil-type transformers, except thermally protected       
devices included in light ballasts, may be installed in 
records storage areas. 
(q)(2)  All electrical wiring must be in metal conduit, except that       
armored cable may be used where flexible wiring 
connections to light fixtures are required  
(q)(3)  Battery charging areas for electric forklifts must be       
separated from records storage areas with at least a 2-hour 
rated fire barrier wall.  1228.230  Requirement  OK  No  Other 
paragraph: 
(r)  Hazardous materials ... must not be stored in records       
storage areas. 
(s)  All records storage and adjoining areas must be protected       
by a professionally designed fire-safety detection and 
suppression system that is designed to limit the maximum 
anticipated loss from any single fire event to a maximum 
of 300 cubic feet of records destroyed. 
For systems in accordance with App. B, attach checklist.  
For other designs, see  1228.242 for documentation 
requirements. 
 
Compliance with 36 CFR 1228.232, Environmental Control Requirements 
1228.232  Requirement  OK  No  Other 
Paragraph: 
(a)  Paper-based temporary records must be stored under       
environmental conditions that prevent the active growth of 
mold.  (See rule text) 
(b)  Nontextual temporary records, including microforms and       
audiovisual and electronic records, must be stored in 
records storage space that will ensure their preservation 
for their full retention period.  Effective 9/28/2005 for new 
records storage facility and 10/1/2009 for existing 
facilities. (See rule text) 
(c)  Paper-based permanent, unscheduled, and sample/select       
records must be stored in records storage space that 
provides 24 hour/365 days per year air conditioning 
equivalent to that required for office space.  (See rule text) 
Effective date: New facilities, 9/28/2005; existing facilities 
10/1/2009 
(d)  Nontextual permanent, unscheduled and/or sample/select       
records:  see parts 1230, 1232, and/or 1234 of 36 CFR 
Chapter XII. 
  List of Attachments 
Description  Yes  N/A 
Minimum Security Requirements Check List (Appendix A)     
Fire-Safety Check List (Appendix B)     
Certification of fire-safety detection and suppression system (36 CFR 1228.242)     
Exceptions caused by Code Conflicts (36 CFR 1228.234)     
Waiver request(s) (36 CFR 1228.236)     
Other: (Describe)     
     
     
     
     
     
     
     
  Notes 
Reference ( and )  Comments 
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
 
Facility Standards for Records Storage Facilities 
Supplemental Check Lists: Appendix A and Appendix B 
 
Compliance with Federal Facility Security Standards, Level III 
(36 CFR Part 1228 Appendix A) (Complete for ALL facilities) 
Citation  Requirement  OK  No  Part 
S1  Control of facility parking       
S2  Receiving/shipping procedures       
S3  Intrusion detection system with central monitoring       
S4  Meets Life Safety Standards        Citation  Requirement  OK  No  Part 
S5  Adequate exits from records storage areas       
S6  High security locks on entrances/exits       
S7  Visitor control/screening system       
S8  Prevent unauthorized access to utility areas       
S9  Provide emergency power to critical systems       
S10  Conduct background security checks and/or establish       
security control procedures for service contract personnel 
 
Compliance with 36 CFR Part 1228 Appendix B 
(Complete this section ONLY if the facility claims to be using the system described in 
Appendix B) 
Paragraph  Requirement  OK  No  Part 
2a.  The records storage height must not exceed the nominal       
15 feet (+/-3 inches) records storage height. 
2b.  All records storage and adjoining areas must be protected       
by automatic wet pipe sprinklers. 
2c.1  1. The sprinkler system must be rated at no higher than       
285 degrees Fahrenheit utilizing quick response (QR) 
fire sprinkler heads. 
2c.2  2. The sprinkler system must be designed by a licensed       
fire protection engineer to provide the specified density 
for the most remote 1,500 square feet of floor area at the 
most remote sprinkler head in accordance with NFPA 13 
(1996), Standard for the Installation of Sprinkler 
Systems. 
2c.3  3. Installation of the sprinkler system must be in       
accordance with NFPA 13 (1996), Standard for the 
Installation of Sprinkler Systems. 
2c.4  4. Contractors Material and Test Certificates per NFPA       
13 chapter 8. 
2c.5  5. Hydraulic Calculations.       
2d.1  1. Maximum spacing of the sprinkler heads must be on a       
10-foot grid.  Paragraph  Requirement  OK  No  Part 
2d.2  2. The positioning of the heads must provide complete,       
unobstructed coverage, with a clearance of not less than 
18 inches, but not more than 60 inches, from the top of 
the highest stored materials. 
2e.  The sprinkler system must be equipped with a water-      
flow alarm connected to a continuously staffed fire 
department or central station, with responsibility for 
immediate response. 
2f.1  1. A manual fire alarm system must be provided with       
central station services or other automatic means of 
notifying the municipal fire department. 
2f.2  2. A manual alarm pull station must be located adjacent       
to each exit. 
2g.  All water cutoff valves in the sprinkler system must be       
equipped with automatic closure alarm connected to a 
continuously staffed station, with responsibility for 
immediate response. 
2h.  A dependable water supply free of interruption must be       
provided.  This normally requires a backup supply 
system having sufficient pressure and capacity to meet 
both fire hose and sprinkler requirements for 2 hours. 
2i.  Interior stand-pipe stations equipped with 1 12 inch       
diameter hose may be provided in the records storage 
areas if required by the local fire department, enabling 
any point in the records storage area to be reached by a 
50-foot hose stream from a 100-foot hose lay.  If hose is 
provided, the cabinets must be marked For Fire 
Department Use Only. 
2j.  Where fire hose cabinets are not required, stand-pipes       
must be provided at each floor landing in the building 
core or stair shaft.  Hose outlets must have easily 
removable adapter and cap.  Threads and valves must be 
compatible with the local fire departments equipment.  
Spacing must be so that any point in the records storage 
area can be reached with a 50-foot hose stream from a 
100-foot hose lay.  Paragraph  Requirement  OK  No  Part 
2k.  In addition to the designated sprinkler flow demand, 500       
gpm must be provided for hose stream demand.  The 
hose stream demand must be calculated into the system 
at the base of the main sprinkler riser. 
2l.1  1. Fire hydrants must be located within 250 feet of each       
exterior entrance or other access to the records center 
that could be used by fire-fighters. 
2l.2  2. All hydrants must be at least 50 feet away from the       
building walls and adjacent to a roadway usable by fire 
apparatus.  Fire hydrants must have at least two 2-12 inch 
hose outlets and a pumper connection.  All threads must 
be compatible with local standards. 
2m.  Portable water-type fire extinguishers (212 gallon stored-      
pressure type) must be provided at each fire alarm 
striking station (see also NFPA 10). 
2n.1  1. Where provided, the walking surface of the catwalks       
must be of expanded metal at least 0.09-inch thickness 
with a 2-inch mesh length. The surface opening ratio 
must be equal or greater than 0.75. 
2n.2  2. The sprinkler water demand for protection over bays       
with catwalks where records are not oriented 
perpendicular to the aisles must be calculated to give 0.3 
gpm per square foot for the most remote 2,000 square 
feet. 
 
Notes 
Reference  Comments 
   
   
   
   
   
    Reference  Comments 
   
   
   
   
   
 
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 SSMs 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 CMSs 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 systems 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 STCs 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  System  Calendar  System Run  Calendar 
System Run Date 
Date  Run Date  Date  Date  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. 
 
Allowable Values or  Comments 
Data Element  Description  Format 
Test Case  Multi-part indicator that  See Test Case   
Specification  uniquely identifies the test  Specification Identifier 
Identifier  case specification.  Standard. 
Test Purpose  A free form field that  See attached example.   
captures the intent of the test 
and identifies any key 
components of the test, e.g., 
specific codes.  Input  A free form field that  See attached example.   
Specification  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 
Intercase  The test case specification  See Test Case   
Dependencies  identifier of the transaction  Specification Identifier 
(Predecessor  that must be entered into and  Standard. 
Transaction  processed by the system prior 
Identifier)  to processing the transaction 
described by the test case 
specification. 
Output  A free form declarative     
Specification  statement that identifies the 
expected results from 
performing all the steps, as a 
collection, within the test.  
Test Type  A one-character indicator to  P = Positive Test 
ALM 
identify whether the test is  N = Negative Test 
Plan Tab 
positive or negative.   
(Required 
Originator  A one-character indicator to  B = Beta 
User Defined 
identify the originating entity  C = CMS/QRTM 
Fields) 
(designer) of the test case.   M = Maintainer 
Test Status  Summary indicator for a test  PS = Passed   
case.  FA= Failed  Required 
NR = Not Run  Test  
IN = Incomplete  Execution 
ID = Invalid Data  (Run) 
IC = Invalid Case  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 n   
step.  Where n is a sequential   
  counter for each step   
starting at 1.   
There is at least one test   
step in each test case  Optional 
specification, but usually  Test 
contains multiple test steps.  Case 
Step  A free form declarative    Elements 
Description  statement that identifies the 
action taken to perform the 
test.  The step description 
statement usually begins with 
a verb. 
 
Expected Step  A free form declarative   
Results  statement that identifies the 
expected results from 
performing the associated 
step description. 
 
 
Example #1 
  Test Case Identifier  4419-2825-5.2-001 
  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 
Test Purpose 
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. 
n  Claims History  None 
o Beneficiary  Beneficiary must be unlawfully present in United States. 
ut cati Information  Beneficiary elected English as primary language  
pi
nif Provider Information  Provider Number Range = XX0001-XX0999 
Ic
pe Claim Data  TOB = 111  
S
Requirements  DOS = 01/01/2004 
  Intercase 
None 
Dependencies 
  Claim will be assigned reason code 30 indicating beneficiary is not 
lawfully present in the United States, generating MSN message 5.7 
Output Specification  (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 
FISS, 
Electronic Correspondence Referral System functionality (ECRS) - The STC 
1  MCS, 
does not interface with ECRS.   
VMS 
Recovery Audit Contractor (RAC) and/or Recovery Audit Contractor Data 
FISS, 
Warehouse (RACDW) - The STC does not interface with the RAC or the 
2  MCS, 
RACDW. The STC does have the ability to test RAC related changes in the 
VMS 
shared system applications. 
FISS,  Non-Base Job System Processing.  The STC does not test non-base jobs. 
3  MCS, 
VMS 
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. 
FISS, 
Local Coverage Determinations (LCDs) - The STC does not test MAC LCD or 
7  MCS, 
medical policy.   MACs conduct LCD and medical policy testing. 
VMS 
Interactive Voice Response (IVR) - STC would not do end-to-end testing of 
8  MCS  MCS base system changes for the IVR. The STC does have the ability to test 
IVR related changes in the shared system.     
Automated Response Unit (ARU) - STC would not do end-to-end testing of 
9  MCS  MCS base system changes for the ARU. The STC does have the ability to test 
ARU related changes in the shared system.     
FISS, 
Optical Character Recognition (OCR) - The STC does not test changes to OCR 
10  MCS, 
functionality.  
VMS 
FISS, 
MCS,  Contractor ID specific logic  The STC is unable to conduct state or jurisdiction 
11 
VMS,  specific testing that requires a specific contractor number for processing. 
CWF 
FISS, 
Printing  The STC does not have a print vendor and does not test backend 
12  MCS, 
print/mail functions.  
VMS  FISS, 
Testing that requires large volumes of data  The STC environment contains a 
MCS, 
13  limited number of claims.  Thus, the STC may not be able to identify volume-
VMS, 
related issues in its test environment. 
CWF 
Runbooks are documentation artifacts maintained by the SSMs that provide 
instructions regarding how jobs are to be scheduled (daily, weekly, monthly, on 
FISS, 
request etc.) and predecessor/successor relationships for jobs that must precede 
MCS, 
14  or succeed, as well as containing comments on known abend return codes the 
VMS, 
job is programmed to return sometimes including instructions on how to 
CWF 
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.  
Processes that are designed to only work in a test environment - Processes that 
FISS, 
are designed to only work in a test environment and will never be promoted or 
MCS, 
16  utilized in the production environments. This includes the internal testing 
VMS, 
facility (ITF), the CWF response generator, the HIGLAS response generator, 
CWF 
and the MBI generator.  
FISS,  Healthcare Integrated General Ledger Accounting System (HIGLAS) - The 
17  MCS,  STC is not responsible for testing HIGLAS changes. The shared systems will 
VMS  continue to test HIGLAS. 
INFOMAN - The STC does not test CRs implemented by the FISS SSM that 
18  FISS 
update the release identifier on the main CICS screen in the FISS application.     
FISS,  Electronic Funds Transfer (EFT) - The STC does not conduct testing with 
19  MCS,  financial institutions, and is therefore unable to test the EFT transactions. The 
VMS,   STC inspects the EFT files created from the shared systems and processes them.  
Payment File Development Contractor (PFDC) - The STC does not interface 
FISS,  with the PFDC system. Changes to the file are tested by the STC by manually 
20 
MCS  sending and receiving a file. The STC inspects the files created from the shared 
systems and processes them. 
FISS, 
Integrated Data Repository (IDR) - The STC can test IDR file changes as part 
MCS, 
21  of the shared system, but the files are not automatically sent to the IDR 
VMS, 
contractor.  STC manually sends files to the IDR contractor twice during the 
CWF   release. The STC inspects the files for accuracy created from the shared systems 
and processes them. 
Quality Improvement Evaluation System (QIES) - The STC does not interface 
22  FISS  with QIES.  The STC inspects the files for accuracy created from the shared 
systems and processes them. 
FISS, 
Provider Statistical and Reimbursement System (PS&R) - The STC does not 
MCS, 
23  interface with the PS&R system.  The STC inspects the files for accuracy 
VMS, 
created from the shared systems and processes them. 
CWF  
FISS, 
Production Performance Monitoring System (PULSE) - The STC does not 
MCS, 
24  interface with PULSE. The STC inspects the files for accuracy created from the 
VMS, 
shared systems and processes them. 
CWF   
Provider Enrollment System (PES) - The STC does not have the PES 
25  MCS  application that is used exclusively by the Railroad Retirement Board Specialty 
MAC.  The STC is unable to test the PES application. 
FISS,  Provider Enrollment Chain and Ownership (PECOS) - The STC does not utilize 
26  MCS,  the PECOS system to generate enrollments.  STC manually creates a file when 
VMS  needed for testing.  
FISS,  Electronic Submission of Medical Documentation (esMD) - The STC does not 
27  MCS,  have connectivity with esMD. The STC does have the ability to test esMD 
VMS  related changes in the shared system.     
Affordable Care Organization (ACO)  The STC does not have connectivity 
28  CWF   with the ACO. The STC does have the ability to test ACO related changes in the 
shared system.     
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 
29  CWF 
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. 122, Issued: 12-21-18, Effective: 05-28-19 Begin with Quarter 2 report in 2019, 
Implementation: 05-28-19 Begin with Quarter 2 report in 2019) 
 
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 28th 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 
contractors 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 CMSs 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 instructions 
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 CRs 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 complete this field with the CMS CR 
transmittal numbers implemented during the quarter.  If a CR was issued with multiple 
transmittals, the word multiple will be entered in 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.  MLN 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) - Applies only in situations where CMS issued 
the MLN Matters Article more than three days after the CR was posted on the CMS website. 
The contractor should include a comment in Item 13 that explains the activity that was not 
completed and the quarter in which the activity will be completed.  If a contractors quarterly 
bulletin is due to go out in another quarter, the CR should be added as an add-on in the quarter in 
which the activity occurred, including a comment that all activity for that CR has been 
completed. 
 
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) - Provide explanation for delay along with the MLN reference number 
of the specific MLN  and published date. 
 
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 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 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. 
 
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 (CMSs) 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 
Contractors (MACs) 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# 
R128GI  11/01/2019  Update to General Information, Eligibility,  12/03/2019  11518 
and Entitlement, Chapter 7 - Contract 
Administrative Requirements, Section 40.2 
 Shared System Maintainer 
Responsibilities for Systems Releases 
R125GI  07/05/2019  Internet Only Manual (IOM) - Update to  08/05/2019  11245 
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 
R124GI  05/17/2019  Update to Publication (Pub.) 100-01 to  06/18/2019  11240 
Provide Language-Only Changes for the 
New Medicare Card Project 
R122GI  12/21/2018  Updated Instructions for the Change  05/28/2019  11067 
Request Implementation Report (CRIR) and 
Technical Direction Letter (TDL) 
Compliance Report (TCR) 
R108GI  11/03/2017  MAC Transition Workload Handbook  12/04/2017  10329 
R105GI  06/02/2017  Update to General Information, Eligibility,  07/03/2017  10062 
and Entitlement, Chapter 7 - Contract 
Administrative Requirements, Section 40  
Shared System Maintainer Responsibilities 
for Systems Releases 
 
R102GI  11/02/2016  Internet Only Manual (IOM) Publication  11/02/2016  9785 
100-01 - General Information, Eligibility, 
and Entitlement, Chapter 7 - Contract 
Administrative Requirements, Section 40  
Shared System Maintainer Responsibilities 
for Systems Releases 
R100GI  06/23/2016  Medicare Fee-for-Service Change Request  07/05/2016  9455 
Correction and Rescind Process  R99GI  06/10/2016  Medicare Fee-for-Service Change Request  06/10/2016  9455 
Correction and Rescind Process  
Rescinded and replaced by Transmittal 100 
R97GI  01/15/2016  Internet Only Manual (IOM) Publication  09/21/2015  9219 
100-01 - General Information, Eligibility, 
and Entitlement, Chapter 7 - Contract 
Administrative Requirements, Section 40  
Shared System Maintainer Responsibilities 
for Systems Releases 
R95GI  10/16/2015  Internet Only Manual (IOM) Publication  09/21/2015  9219 
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 
R93GI  08/21/2015  Internet Only Manual (IOM) Publication  09/21/2015  9219 
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 
R90GI  02/12/2015  Rescinds/Replaces CR 7468 - Updated  05/28/2015  8598 
Instructions for the Change Request 
Implementation Report (CRIR) and 
Technical Direction Letter (TDL) 
Compliance Report (TCR) 
R88GI  08/25/2014  Rescinds/Replaces CR 7468 - Updated  09/11/2014  8598 
Instructions for the Change Request 
Implementation Report (CRIR) and 
Technical Direction Letter (TDL) 
Compliance Report (TCR)  Rescinded and 
replaced by Transmittal 90 
R87GI  08/08/2014  Update to Pub. 100-01, Chapter 7 for  Upon  8639 
Language-Only Changes for ICD-10  Implementati
on of ICD-10 
R86GI  05/16/2014  Rescinds/Replaces CR 7468 - Updated  08/28/2014  8598 
Instructions for the Change Request 
Implementation Report (CRIR) and 
Technical Direction Letter (TDL)  Compliance Report (TCR)  Rescinded and 
replaced by Transmittal 88 
R83GI  03/07/2014  Update to Pub. 100-01, Chapter 7 for  10/01/2014  8639 
Language-Only Changes for ICD-10  
Rescinded and replaced by Transmittal 87 
R75GI  12/30/2011  Contractor Implementation of Change  05/28/2012  7468 
Requests and Compliance With Technical 
Direction Letters  Rescinded and replaced 
by CR 8598 
R66GI  01/07/2011  Change Request (CR) Definitions  02/08/2011  6592 
R59GI  10/30/2009  The CMS Standard File for Reason Codes  04/05/2010  6529 
for the Fiscal Intermediary Shared System 
(FISS) 
R57GI  02/20/2009  Implementing Validated Workarounds for  03/20/2009  6379 
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 
R54GI  10/01/2008  IDR Claims Sourcing From Shared  01/05/2009  5949 
Systems-Implementation 
R53GI  09/26/2008  Medicare Contractor Testing with Future  10/27/2008  6110 
Dates in the EDC 
R52GI  07/11/2008  Change to CR Implementation Report Due  08/11/2008  6102 
Dates 
R51GI  05/16/2008  IDR Claims Sourcing From Shared  10/06/2008  5949 
Systems-Implementation - Rescinded and 
Replaced by Transmittal 54 
R46GI  07/20/2007  Implement New Contractor ID for Single  01/07/2008  5648 
Testing Contractor (STC) 
R44GI  05/25/2007  Fee-for-Service Contractor Transition  07/02/2007  5446 
Handbooks 
R43GI  03/30/2007  Clarification in Testing Instructions for  07/02/2007  5395 
Definition of Local Components  R38GI  05/26/2006  Files Maintenance Program Update to the  06/26/2006  5055 
Internet-Only Manual (IOM) 
R34GI  01/06/2006  Change Management Process -- Electronic  01/03/2006  4092 
Change Information Management Portal 
(eChimp)  
R33GI  12/30/2005  Change Management Process -- Electronic  01/03/2006  4092 
Change Information Management Portal 
(eChimp) 
R30GI  10/28/2005  Initiate STC testing of the MCS for RRB  04/03/2006  4150 
and HIGLAS 
R26GI  07/22/2005  Implement New Medicare Plan ID and  10/03/2005  3978 
Carrier Number for the Single Testing 
Contractor (STC) 
R25GI  07/15/2005  Next Generation Desktop (NGD) Testing  08/15/2005  3493 
Requirements 
R24GI  05/27/2005  2005 Scheduled Release for July Updates to  06/27/2005  3865 
Software Programs and Pricing/Coding 
Files 
R23GI  05/06/2005  Procedures for Modifying Shared Systems  10/03/2005  3862 
Edits and Capturing Audit Trail Data 
R17GI  02/25/2005  Review of Contractor Implementation of  03/01/2005  2884 
Change Requests (Replacement for expired 
CR 944) 
R16GI  01/28/2005  Standard Terminology for Claims  04/04/2005  3596 
Processing Systems 
R15GI  01/21/2005  Review of Contractor Implementation of  03/01/2005  2884 
Change Requests (Replacement for expired 
CR 944) 
R08GI  07/30/2004  Establish Standard Terminology for  01/03/2005  3086 
Medicare Shared Systems 
R06GI  05/2//2004  CMS Policy for Testing Quarterly Release  08/01/2004  3011 
of the Medicare Shared Systems and the 
CWF 
R05GI  05/07/2004  Initial Publication of Chapter  N/A  2765 
Back to top of Chapter