CMS Pub. 100-01, ch. 7
(Rev. 13175; Issued: 04-17-25)
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
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06)
(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:
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.
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06)
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.)
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.
These include records that are not included as claims or non-claims records. See §30.70 for the records retention and disposal schedule.
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.
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.
(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.
(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.
(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.
(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.
(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.
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06)
All paper claims that are microfilmed must be retained until CMS notifies you the freeze is lifted.
The master microform must be retained until CMS notifies you the freeze is lifted.
(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.
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06)
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.
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.
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.
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.
(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.
(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.
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.
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.
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.
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.
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.
This category includes files accumulated when a beneficiary, physician, provider, or other supplier of service is dissatisfied with the MAC's 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.
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 MAC’s 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.
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.
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.
These files consist of form TSF-5805, Request for Funds, and similar documents prepared by the A/B MAC (B) or DME MAC’s 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.
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.
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 MAC's 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.)
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.
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.
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.
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.
Consists of documents relating to Part B A/B MAC (B) or DME MAC performance. Submitted on a weekly basis electronically to CMS’s data center.
Disposition: Destroy after 6 months.
(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.
(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.
(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.
| 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 |
(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 |
(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.
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06)
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.
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 START OF FILM | LEADER <ABOUT- 2 FEET | ROLL NUMBER CARD | TITLE CARD | FILING SEQUENCE CARD | START CERTIFICATION OF AUTHENTICITY CARD | TEST* CHART |
|---|---|---|---|---|---|---|
| \ | LAST | \ | ||||
|---|---|---|---|---|---|---|
| / | LAST | CERTIFICATE | / | |||
| \ | DOCUMENT | DOCUMENT | DOCUMENT | DOCUMENT | OF AUTHENTICITY CARD | \ |
| / | / | |||||
| \ | \ |
| / | *Filmed Twice Each Day | \ | |||
|---|---|---|---|---|---|
| \ | END | ← | TRAILER ABOUT | END OF FILM | / |
| / | CARD | 2 FEET | / | \ | |
| \ | / |
| \ | |||||
|---|---|---|---|---|---|
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) | \ | ||
| / | / | |||||
| \ | \ |
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 | / | |||
| \ | \ |
(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 |
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06)
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.)
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.
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.
(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
(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.
(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.
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06)
Exhibit 12. Roll Report
Exhibit 13 Report of Medicare Records
Exhibit 14 Inspection Checklist -- Standards for Record Storage Facilities
(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) |
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.
(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.
(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
(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
(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
(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
(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
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06)
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.
(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
(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
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06)
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: _____
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06)
THEIR ROLL NO.
AGENCY
NAME
OUR ORDER
NUMBER
CAMERA NO.
LIGHT LEVEL
IRIS
REDUCTION
FILMING TIME
LUNCH
TIME
BREAK
TIME
PREP
TIME
WAITING
TIME
SET-UP
TIME
TRAVEL
TIME
DATE PROC.
DEV. TIME
CHEM. TEMP
REMARKS
PROCESSOR
APPROVED
RESHOOTS
FOOTAGE
INSPEC.
TIME
INSPECTORS
INITIALS
DENSITY
RESHOOTS WILL BE FOUND ON
THIS ROLL FOR ROLL NUMBERS
REMARKS
OPERATOR'S INITIALS
(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 Room | Offsite Storage | 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...1½ 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...¼ cubic foot per 12” case holder
(Rev. 38, Issued: 05-26-06, Effective: 06-26-06, Implementation: 06-26-06)
| Agency: | |
|---|---|
| Facility: Common Name: | |
| Facility: Street Address | |
| Facility: City, State & Zip | |
| Facility Director or Representative: | <> <> ☐ Comments explaining or disagreeing with inspection findings are attached. |
| Inspector: | <> Date <> |
| Facility Description: |
| §1228.228 paragraph: | Requirement | OK | No | Other |
|---|---|---|---|---|
| (a) | The facility must be constructed with non-combustible materials and building elements, including walls, columns, and floors. | |||
| (a) exception 1 | If the roof is constructed of combustible material it is protected by a properly installed and maintained wet-pipe automatic sprinkler system. | |||
| (a) exception 2 | Existing records storage facility with combustible building elements has an approved waiver from NAS that allows 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 paragraph: | Requirement | OK | No | Other |
|---|---|---|---|---|
| (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). | |||
| (n)(2) | (2) No high-voltage electrical distribution equipment (i.e., 13.2kv or higher) in records storage areas. |
| §1228.228 paragraph: | Requirement | OK | No | Other |
|---|---|---|---|---|
| (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. |
| §1228.230 paragraph: | Requirement | OK | No | Other |
|---|---|---|---|---|
| (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. | |||
| (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. |
| §1228.230 paragraph: | Requirement | OK | No | Other |
|---|---|---|---|---|
| (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 ½ hour. | |||
| (e) alternate | Unrated roof is protected in accordance with NFPA 13. | |||
| (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) alternate | Unrated columns are protected in accordance with NFPA 13. | |||
| (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. | |||
| (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) |
| §1228.230 paragraph: | Requirement | OK | No | Other |
|---|---|---|---|---|
| (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. | |||
| (r) | Hazardous materials … must not be stored in records storage areas. |
| §1228.230 paragraph: | Requirement | OK | No | Other |
|---|---|---|---|---|
| (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. |
| §1228.232 Paragraph: | Requirement | OK | No | Other |
|---|---|---|---|---|
| (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. |
| Description | Yes | N/A |
|---|---|---|
| Minimum Security Requirements Check List (Appendix A) |
| Description | Yes | N/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 |
|---|---|
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 | |||
| S5 | Adequate exits from records storage areas |
| Citation | Requirement | OK | No | Part |
|---|---|---|---|---|
| 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 |
(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. Contractor's 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 ½ 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 department’s 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. | |||
| 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. |
| Paragraph | Requirement | OK | No | Part |
|---|---|---|---|---|
| 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-½ inch hose outlets and a pumper connection. All threads must be compatible with local standards. | |||
| 2m. | Portable water-type fire extinguishers (2½ 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. |
| Reference | Comments |
|---|---|
| Reference | Comments |
|---|---|
(Rev. 97, Issued: 01-15-16, Effective: 09-21-15, Implementation: 09-21-15)
(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.
(Rev. 105, Issued: 06-02-17, Effective: 07-03-17, Implementation: 07-03-17)
| STANDARD TERMINOLOGY | DESCRIPTION |
|---|---|
| QUESTION (QCN) | Request for assistance and/or reported potential system problem. For questions, the MACs and the STC shall contact the SSM’s helpdesk to log their question. |
| PROBLEM | Confirmed system and/or documentation problem |
| Change Request (CR) | Any software modification made to the system as a result of a CMS mandate or maintainer initiated action |
| CMS STATUS | CMS needs take action by answering a question, finalizing an instruction, etc. |
| NSC (non-system change) STATUS | CMS CR does not require shared system change. May require A/B MAC maintenance |
| RESEARCH STATUS | The SSM completes high level review of required changes by analyzing them and determining the intent of the change request |
|---|---|
| REQUIREMENTS (REQS) STATUS | The SSM finalizes the business requirements |
| WALKTHROUGH STATUS | The SSM presents the systems solution to the CR in a structured walkthrough discussion with CMS and Beta testers |
| WORK STATUS | The SSM completes technical design, coding and unit testing the system change |
| STANDARD TERMINOLOGY | DESCRIPTION |
|---|---|
| ALPHA TESTING | Functional testing performed by the SSM, after successful unit testing of the new or modified code; which starts approximately ninety (90) days prior to the implementation of the Change Request. The testing verifies all changed components function appropriately within the full environment at the SSM site in a controlled environment. |
| BETA TESTING | This is the second phase of testing after Alpha testing. The goal of Beta testing is to identify and resolve any remaining defects before a product/software is released to a production environment. Beta testing begins eight weeks prior to the production implementation date of a quarterly release. The Beta tester continues to test all iterations of the code through the UAT testing phase until the release moves to production. The Beta tester continues to test for two weeks post production or until they are 100% completed, whichever comes first. |
| User Acceptance Testing (UAT) | MACs and DME MACs perform UAT testing during the four weeks prior to the production implementation date of a quarterly release. |
| USER STATUS | The SSM returns question to user to provide more information or examples, assess solution |
(Rev.: 128, Issued: 11-01-19, Effective: 12-03-19, Implementation: 12-03-19)
(Rev. 13175; Issued: 04-17-25; Effective: 05-19-25; Implementation: 05-19-25)
Shared System Maintainers (SSMs) shall obtain approval from their Government Task Leader (GTL) before quarterly release software can be scheduled and installed.
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.
Listed below are CMS’s problem priority classifications and examples.
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.
EXAMPLES:
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:
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
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:
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:
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:
Priority 4 Classification
Production:
The problem is an operator inconvenience or annoyance, which does not affect a required mission essential capability.
EXAMPLES:
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:
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:
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:
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.
(Rev. 97, Issued: 01-15-16, Effective: 09-21-15, Implementation: 09-21-15)
Medicare A/B, DME contractors shall implement workarounds within the shared systems for problems when formally defined as a Priority 3 or Priority 4 without obtaining written permission from a Project Officer or Regional Office.
Shared system problems that are formally defined as a Priority 3 or a Priority 4 have acceptable workarounds which provide temporarily alternative solutions. In order for a A/B/DME MACs to implement a workaround, the shared system maintainer must first validate the problem, confirm that the workaround exists, is systematically viable and does not cause adverse effects. The implementation of such workarounds will eliminate delay in adjudication of Medicare claims and the payment to providers. Utilizing a Priority 3 or Priority 4 workaround shall not diminish the integrity of the shared systems and shall not include such actions as deactivating standard edits. The shared system's priorities are formally defined at Section 40.2 of this chapter.
(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.
(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.
(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.
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:
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:
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:
Example: Two test cases were developed to test the implementation of Requirement 22522-2634-2.8 (see example above). The unique Test Case Identifier for the two test cases would be 22522-2634-2.8-01 and 22522-2634-2.8-02.
5. The Shared System Maintainers and the Single Testing Contractor (STC) shall document and execute both positive and negative test cases to ensure the requirements of the release are correctly implemented. - Positive test cases are required to ensure that the system is directly fulfilling the requirements as specified. One or more positive test cases are required for each requirement. As an example, if a program mandate effects a change for services beginning on July 1, a positive test case would include service dates in July or later and validate that the actual mandate was correctly implemented. - Negative test cases test cases are required to ensure that the system does not perform an incorrect action. As an example, if a program mandate effects a change for services beginning on July 1, a negative test case would ensure that implementing the mandate did not negatively impact claims with service dates prior to July 1. Unlike positive test cases, a negative test case may not be applicable to every requirement within a CR. Additionally, although due diligence might necessitate a negative test case, the need may be mitigated by an existing case in your regression test set.
6. The Shared System Maintainers and the Single Testing Contractor (STC) shall document all test cases and the actual results for each test case electronically. Each test case and the associated results must be stored in a test management repository (i.e., Application Lifecycle Management (ALM) tool) and must at a minimum contain the data elements outlined in the
CMS Test Case specification standard. See subsection 40.3.10 for the Test Case specification standard.
7. The Shared System Maintainers and the Single Testing Contractor (STC) shall maintain a test log that provides a record of each test execution. Test Log requirements may be fulfilled by correctly using the ALM “run” feature (or an equivalent tool or approach) as outlined in the Quarterly Release Test Management User Guide.
8. The Shared System Maintainers and the Single Testing Contractor (STC) shall execute a full regression test set on their system for every quarterly release. Each testing entity shall perform regression testing within their designated testing window as outlined in subsection 40.3.7, Timeframe Requirements.
9. The Shared System Maintainers and the Single Testing Contractor (STC) shall perform interface testing.
The Shared System Maintainers and the Single Testing Contractor (STC) shall validate that all output files are correctly created by their system. The SSMs and STC shall validate that their system can accept and correctly process all input files.
The Shared System Maintainers and the Single Testing Contractor (STC) shall perform interface testing that includes full data exchanges (both ways) between the shared system and any principal claims processing adjudication or financial system (e.g., the CWF and HIGLAS respectively). The STC is required to perform data exchanges with HIGLAS after HIGLAS is implemented at the STC’s data center.
The Shared System Maintainers and the Single Testing Contractor (STC) shall complete an integrated system test coordinating the maintenance of test data baselines, such as beneficiary data, with the CWF Beta tester.
(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.
(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.
(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:
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:
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
2. 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.
1. 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.
2. 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.
3. 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.
4. 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.
5. e. The FWG or DMOP TAG shall maintain their “run-date simulation” schedule for a minimum of 14 calendars days in advance. Here is an example of a “run-date simulation” schedule:
| Calendar Date | System Run Date | Calendar Date | System Run Date | Calendar Date | System Run Date |
|---|---|---|---|---|---|
| 10/8/2015 | 10/5/2015 | 10/17/2015 | 10/14/2015 | 10/26/2015 | 10/23/2015 |
| 10/9/2015 | 10/6/2015 | 10/18/2015 | 10/15/2015 | 10/27/2015 | 10/24/2015 |
| 10/10/2015 | 10/7/2015 | 10/19/2015 | 10/16/2015 | 10/28/2015 | 10/25/2015 |
| 10/11/2015 | 10/8/2015 | 10/20/2015 | 10/17/2015 | 10/29/2015 | 10/26/2015 |
| 10/12/2015 | 10/9/2015 | 10/21/2015 | 10/18/2015 | 10/30/2015 | 10/27/2015 |
| 10/13/2015 | 10/10/2015 | 10/22/2015 | 10/19/2015 | 10/31/2015 | 10/28/2015 |
| 10/14/2015 | 10/11/2015 | 10/23/2015 | 10/20/2015 | 10/1/2015 | 10/29/2015 |
|---|---|---|---|---|---|
| 10/15/2015 | 10/12/2015 | 10/24/2015 | 10/21/2015 | 10/2/2015 | 10/30/2015 |
| 10/16/2015 | 10/13/2015 | 10/25/2015 | 10/22/2015 | 10/3/2015 | 10/1/2015 |
f. The FISS FWG, MCS FWG, and DMOP/CFM TAG shall provide a copy of their “run-date simulation” schedule to their CWF test host.
g. The FISS FWG and MCS FWG shall provide a copy of their “run-date simulation” schedule to the HIGLAS test site as required to accommodate their HIGLAS enabled contractors.
(Rev. 97, Issued: 01-15-16, Effective: 09-21-15, Implementation: 09-21-15)
Each CWF data center or CWF sector host shall:
(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:
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.
(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:
2. The SSM, STC, and MAC shall:
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.
(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.
(Rev. 97, Issued: 01-15-16, Effective: 09-21-15, Implementation: 09-21-15)
Purpose: This standard establishes a controlled outline for the contents and presentation of a Test Case Specification used by the shared system maintainers and the STC.
Applicability: This standard is applicable to all Test Case Specifications developed by the shared system maintainers and the STC.
| Data Element | Description | Allowable Values or Format | Comments |
|---|---|---|---|
| Test Case Specification Identifier | Multi-part indicator that uniquely identifies the test case specification. | See Test Case Specification Identifier Standard. | |
| Test Purpose | A free form field that captures the intent of the test and identifies any key components of the test, e.g., specific codes. | See attached example. | |
| Input Specification | A free form field that captures critical information used to exercise the system functionality. Information could be grouped into the following topics: Claim Data Requirements Claims History Beneficiary Information Provider Information | See attached example. |
| Intercase Dependencies (Predecessor Transaction Identifier) | The test case specification identifier of the transaction that must be entered into and processed by the system prior to processing the transaction described by the test case specification. | See Test Case Specification Identifier Standard. | |
|---|---|---|---|
| Output Specification | A free form declarative statement that identifies the expected results from performing all the steps, as a collection, within the test. | ||
| Test Type | A one-character indicator to identify whether the test is positive or negative. | P = Positive Test N = Negative Test | ALM Plan Tab (Required User Defined Fields) |
| Originator | A one-character indicator to identify the originating entity (designer) of the test case. | B = Beta C = CMS/QRTM M = Maintainer | |
| Test Status | Summary indicator for a test case. | PS = Passed FA = Failed NR = Not Run IN = Incomplete ID = Invalid Data IC = Invalid Case | Required Test Execution (Run) Elements |
| Test Results | Free form declarative statement of actual results for a test case when the actual results do not match the expected results. |
Optional Information: Industry best practices demonstrate that additional granularity may be necessary to document discrete key test actions that should be executed and documented. These items are referred to as test steps. A test case specification may have one or more test steps. When documenting test steps, the following standard applies:
| Step Number | Unique identifier for each test step. | “Step n” Where “n” is a sequential counter for each step starting at 1. There is at least one test step in each test case specification, but usually contains multiple test steps. | Optional Test Case |
|---|---|---|---|
| Step Description | A free form declarative statement that identifies the action taken to perform the test. The step description statement usually begins with a verb. | Elements | |
|---|---|---|---|
| Expected Step Results | A free form declarative statement that identifies the expected results from performing the associated step description. |
Example #1
| Test Case Identifier | 4419-2825-5.2-001 | |
|---|---|---|
| Test Purpose | To confirm that the A/B MAC (A) claims processing systems accept, process, and assign reason code 30 (Payment adjusted because the patient has not met the required eligibility, spend down, waiting or residency requirements) to Inpatient Hospital claims submitted on Type of bill (TOB) 111 (Hospital Inpatient Part A; admit through discharge) with Dates of Service (DOS) on 01/01/2004 when a beneficiary is not lawfully present in the United States. | |
| Input Specification | Claims History | None |
| Beneficiary Information | Beneficiary must be unlawfully present in United States. Beneficiary elected English as primary language | |
| Provider Information | Provider Number Range = XX0001-XX0999 | |
| Claim Data Requirements | TOB = 111 DOS = 01/01/2004 | |
| Intercase Dependencies | None | |
| Output Specification | Claim will be assigned reason code 30 indicating beneficiary is not lawfully present in the United States, generating MSN message 5.7 (Medicare payment may not be made for the item or service because on the date of service, you were not lawfully present in the United States). | |
| Test Type | P | |
| Originator | C | |
| Test Status | PS | |
| Test Results | Claim was assigned appropriate reason code |
(Rev. 125; Issued: 07-05-19, Effective: 08-05-19, Implementation: 08-05-19)
| ID | LOB | STC Not Testable Conditions and Potential Testing Impacts |
|---|---|---|
| 1 | FISS, MCS, VMS | Electronic Correspondence Referral System functionality (ECRS) - The STC does not interface with ECRS. |
| 2 | FISS, MCS, VMS | Recovery Audit Contractor (RAC) and/or Recovery Audit Contractor Data Warehouse (RACDW) - The STC does not interface with the RAC or the RACDW. The STC does have the ability to test RAC related changes in the shared system applications. |
| 3 | FISS, MCS, VMS | Non-Base Job System Processing. The STC does not test non-base jobs. |
| 4 | FISS | ECPS events – The STC does not test MAC controlled ECPS events. |
| 5 | VMS | Super Op events - The STC does not test MAC controlled Super Op events. |
| 6 | MCS | SCF Logic - The STC does not test MAC controlled SCF Logic. |
| 7 | FISS, MCS, VMS | Local Coverage Determinations (LCDs) - The STC does not test MAC LCD or medical policy. MACs conduct LCD and medical policy testing. |
| 8 | MCS | Interactive Voice Response (IVR) - STC would not do end-to-end testing of MCS base system changes for the IVR. The STC does have the ability to test IVR related changes in the shared system. |
| 9 | MCS | Automated Response Unit (ARU) - STC would not do end-to-end testing of MCS base system changes for the ARU. The STC does have the ability to test ARU related changes in the shared system. |
| 10 | FISS, MCS, VMS | Optical Character Recognition (OCR) - The STC does not test changes to OCR functionality. |
| 11 | FISS, MCS, VMS, CWF | Contractor ID specific logic – The STC is unable to conduct state or jurisdiction specific testing that requires a specific contractor number for processing. |
| 12 | FISS, MCS, VMS | Printing – The STC does not have a print vendor and does not test backend print/mail functions. |
| 13 | FISS, MCS, VMS, CWF | Testing that requires large volumes of data – The STC environment contains a limited number of claims. Thus, the STC may not be able to identify volume-related issues in its test environment. |
|---|---|---|
| 14 | FISS, MCS, VMS, CWF | Runbooks are documentation artifacts maintained by the SSMs that provide instructions regarding how jobs are to be scheduled (daily, weekly, monthly, on request etc.) and predecessor/successor relationships for jobs that must precede or succeed, as well as containing comments on known abend return codes the job is programmed to return sometimes including instructions on how to rerun/restart each abend return code. As Runbooks are documentation in nature the STC does not test Runbooks. |
| 15 | CWF | Enrollment Database (EDB) - The STC does not interface with the EDB system. |
| 16 | FISS, MCS, VMS, CWF | Processes that are designed to only work in a test environment - Processes that are designed to only work in a test environment and will never be promoted or utilized in the production environments. This includes the internal testing facility (ITF), the CWF response generator, the HIGLAS response generator, and the MBI generator. |
| 17 | FISS, MCS, VMS | Healthcare Integrated General Ledger Accounting System (HIGLAS) - The STC is not responsible for testing HIGLAS changes. The shared systems will continue to test HIGLAS. |
| 18 | FISS | INFOMAN - The STC does not test CRs implemented by the FISS SSM that update the release identifier on the main CICS screen in the FISS application. |
| 19 | FISS, MCS, VMS, | Electronic Funds Transfer (EFT) - The STC does not conduct testing with financial institutions, and is therefore unable to test the EFT transactions. The STC inspects the EFT files created from the shared systems and processes them. |
| 20 | FISS, MCS | Payment File Development Contractor (PFDC) - The STC does not interface with the PFDC system. Changes to the file are tested by the STC by manually sending and receiving a file. The STC inspects the files created from the shared systems and processes them. |
| 21 | FISS, MCS, VMS, CWF | Integrated Data Repository (IDR) - The STC can test IDR file changes as part of the shared system, but the files are not automatically sent to the IDR contractor. STC manually sends files to the IDR contractor twice during the |
| release. The STC inspects the files for accuracy created from the shared systems and processes them. | ||
|---|---|---|
| 22 | FISS | Quality Improvement Evaluation System (QIES) - The STC does not interface with QIES. The STC inspects the files for accuracy created from the shared systems and processes them. |
| 23 | FISS, MCS, VMS, CWF | Provider Statistical and Reimbursement System (PS&R) - The STC does not interface with the PS&R system. The STC inspects the files for accuracy created from the shared systems and processes them. |
| 24 | FISS, MCS, VMS, CWF | Production Performance Monitoring System (PULSE) - The STC does not interface with PULSE. The STC inspects the files for accuracy created from the shared systems and processes them. |
| 25 | MCS | Provider Enrollment System (PES) - The STC does not have the PES application that is used exclusively by the Railroad Retirement Board Specialty MAC. The STC is unable to test the PES application. |
| 26 | FISS, MCS, VMS | Provider Enrollment Chain and Ownership (PECOS) - The STC does not utilize the PECOS system to generate enrollments. STC manually creates a file when needed for testing. |
| 27 | FISS, MCS, VMS | Electronic Submission of Medical Documentation (esMD) - The STC does not have connectivity with esMD. The STC does have the ability to test esMD related changes in the shared system. |
| 28 | CWF | Affordable Care Organization (ACO) – The STC does not have connectivity with the ACO. The STC does have the ability to test ACO related changes in the shared system. |
| 29 | CWF | CWF MBI (Medicare Beneficiary ID) XWALK - There are some connectivity tests that STC cannot execute since the XWALK in STC is set up differently compared to production. The XWALK in the STC environment is embedded in the CWF CICS region that houses all other STC CWF data whereas the XWALK in production is in a separate CICS region called Host K. The STC does not connect to Host K. |
(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 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.
(Rev. 11395, Issued:05-04-2022, Effective:05-31-22, Implementation:05-31-22)
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 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.
Each MAC shall complete and submit one CRIR by jurisdiction, one TCR by jurisdiction, cover Letter/Attestation Statements, and if necessary, a separate explanation document. MACs with multiple jurisdictions may complete a separate sheet within a single Excel workbook for each jurisdiction.
In addition, each contractor shall write and maintain written procedures on its change management process (i.e., Standard Operating Procedures – SOP). Elements should include, but are not limited to, written procedures for the timely processing of CMS instructions (issued CRs and TDLs) from the CMS DRI MAILBOX and CMS TDL MAILBOX, written procedures of the contractor’s CR and TDL distribution process (including, but not limited to, the dissemination of provider education information), written procedures for CR implementation and TDL compliance (including written documentation to verify implementation/compliance).
Contractors shall retain the written documentation to verify CR and TDL implementation/compliance using CMS’s records retention guidelines.
Upon request from CMS, contractors shall supply the written procedures of their change management process, as well as written documentation to verify CR and TDL implementation/compliance to CMS.
Refer to section 50.4.2 of this chapter for the definition of the implementation date.
For any instruction affecting providers, regardless if there are Systems or Non-systems changes, CMS gives at least 90 days’ advance notice to the providers. That is, CMS must issue the instruction at least 90 days prior to the implementation date to give providers enough time to implement the instruction. The vehicle used to alert providers 90 days prior to an instruction’s implementation date is the CMS Quarterly Provider Update, which can be accessed at: http://www.cms.hhs.gov/QuarterlyProviderUpdates/01_Overview.asp
There are four exceptions to the 90 days’ advance notice policy: (1) the instruction is contractor specific and therefore does not affect providers; (2) the instruction is a correction/clarification where the previously issued instruction contained typos or errors of fact or omissions; (3) the instruction is a routine or recurring item (which qualifies it to be included on the Mid-Quarter List in the Provider Update); and (4) the instruction is approved by the CMS Administrator to be published immediately or by a certain date.
If a previously issued instruction is re-issued with revised MAC requirements and a revised implementation date is not specified, MACs shall comply with the revised instruction as soon as possible but no later than 10 business days from the CR's date of issuance.
For a system change, the Initiator of the CR will specify an implementation date that corresponds to one of the quarterly release dates. Usually, the quarterly release date will be the first Monday of the quarter. Non-recurring system changes are usually issued five months in advance of the implementation date. On occasion, an off-cycle release date can be approved by OSORA and/or the Administrator. This exception tends to occur most frequently with the implementation of National Coverage Determinations (NCDs) and corrections to finals.
For a Non-system change that has no impact on providers, the Initiator of the CR may specify the implementation date as 30 days from issuance. For a Non-system change that has provider impact, the Initiator of the CR may specify the implementation date as 90 days from issuance.
After the comment period ends and the Initiator of the CR has addressed all comments, he/she prepares a final CR package for CMS clearance. The last part of the CMS clearance process involves obtaining approval from the Medicare Change Control Board (MCCB). The MCCB, in consultation with the Initiator of the CR, will determine the time period needed for implementing each change request. After the clearance process is completed, the Office of Strategic Operations and Regulatory Affairs/Issuances & Records Management Group (OSORA/IRMG) will insert the actual implementation date before issuing the CR as a final instruction.
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.
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.
Below the header Rows, Detail Rows shall be completed as follows:
1. Item 5 (No.) - This field contains a consecutive number to track the number of CRs on the report. CMS CO will complete this field for all CRs included on the report. If the contractor adds additional CRs, they should continue numbering from the previous CMS entered row in red font. For example, if CMS included 15 CRs on the report, the contractor shall begin numbering in this field with 16 in red font.
2. Item 6 (CMS CR #) - CMS CO will complete this field with the CMS CR numbers implemented during the quarter.
3. Item 7 (CMS Transmittal #) - CMS CO will not complete this field.
4. Item 8 (Subject) - CMS CO will complete this field with the subject for all CMS CRs implemented during the quarter.
5. Item 9 (CMS Published Implementation Date MM/DD/YYYY) - CMS CO will complete this field with the CMS Published Implementation date in MM/DD/YYYY format for all CRs implemented during the quarter.
6. Item 10 (Applicable Workload? ("X" or blank)) - MACs shall complete this field with an "X" for all CRs applicable to their workload or leave the field blank if the CR is not applicable to their workload. The CR is considered applicable to the contractor if any of the business requirements in the CR were required to be implemented by the contractor in the reporting period. Note: Shared System Only CRs (with no MAC responsibility checked) are considered not applicable.
7. Item 11 (Completed by Implementation Date? ("Y", "N", or blank)) - MACs shall complete this field with a "Y" for all CRs implemented on or before the CMS Published Implementation Date indicated in Item 9. MACs shall complete this field with an "N" for all CRs that have not been implemented by the implementation date and MACs must select a Reason for Delay from Item 12. This field shall remain blank if the CR is not applicable to the contractor (i.e. Item 10 is blank).
8. Item 12 (Reasons for Delay (leave blank if implemented by due date)) - This field shall remain blank if the CR has been implemented on or before the CMS Published Implementation date (Item 11 is "Y") or is not applicable to the contractor workload (i.e. Item 10 is blank). MACs shall select one of the following Reasons for Delay from the
drop-down list for all applicable CRs not completed by the CMS Published Implementation date indicated in Item 9 (i.e. Item 10 has an 'x' and Item 11 has a "N"):
01. Due date changed due to TDL
02. Due date changed due to CR
03. Retired: MLN delay is retired as a reason for delay
04. CMS delay of file transmission
05. System related delay
06. CR extension approved or pending
07. Deadline past quarter end date
08. Other
Reason 01 (Due date changed due to TDL) - Applies only in situations where CMS has issued a TDL which directs contractors to hold claims and/or otherwise delay the work related to that specific CR.
Reason 02 (Due date changed due to CR) – Applies only in the following situations:
a. Correction final changed the CMS Published Implementation date to be different than the date indicated in Item 9;
b. CR was rescinded/replaced with a different CR number that changed the CMS Published Implementation date to be different than the date indicated in Item 9;
c. Correction or Rescinded/Replaced CR changed the due date of specific Business Requirements.
Reason 03 (CMS MLN Matters® Article Delay) – Retired
Reason 04 (CMS delay of file transmission) - Applies only in situations when the file needed to complete work indicated in the CR was not available timely (i.e., payment files related to annual recurring CRs such as the HCPCS, Pricer, and OPPS).
Reason 05 (System related delay) – Applies only in the following situations:
a. Shared System Maintainer (SSM) production problem prevents a MAC from completing a specific task in the CR;
b. Non-MAC maintained system (e.g., PECOS, HIGLAS, CWF, etc.) production problem prevents a MAC from completing a specific task in the CR.
Reason 06 (CR extension approved or pending) - Applies only in situations where CMS Contracting Officer Representative (COR) has approved an extension of the implementation date specifically referencing this CR.
Reason 07 (Deadline past quarter end date) - Applies only in the following situations:
a. CRs with multiple implementation dates;
b. CRs that contain instruction for work to be done after the implementation date listed in the CR.
Reason 08 (Other) - Applies in all other situations where the implementation of the CR was delayed, and Reasons for Delay 01 through 07 do not apply.
9. Item 13 (Additional Explanation) - MACs shall enter additional comments regarding the implementation of this CR in this field if a Reason for Delay is selected. Do not update this field for CRs implemented timely.
For the following Reasons for Delay, MACs shall include the following data:
Reason 01 (Due date changed due to TDL) - TDL reference number (TDL-######) of the specific TDL which grants an extension and the date to which the extension was granted. Note the actual implementation date of the CR requirements.
Reason 02 (Due date changed due to CR) - Issued date of the Correction final, CR number and issued date of replacement CR (if applicable), and the revised implementation date. Note the actual implementation date of the CR requirements.
Reason 03 (MLN delay) – Retired
Reason 04 (CMS delay of file transmission) - Name of the delayed file, date that the file was expected, and the date the file was actually received. Note the actual implementation date of the CR requirements.
Reason 05 (System related delay) – Name of the system, specific production problem identification number, description of the issue, and resolution date (if applicable). Note the actual implementation date of the CR requirements.
Reason 06 (CR extension approved or pending) - Name of COR, date approval received, and the revised due date. Note the actual implementation date of the CR requirements.
Reason 07 (Deadline past quarter end date) - Note impacted business requirement numbers and the delayed implementation date(s). MACs shall add this CR to the bottom of the CRIR report in red font for the CRIR report of the quarter where MACs completed their work.
Reason 08 (Other) – Explanation of the delay for situations not applicable to Reasons for Delay 01 through 07. Use the space allowed in Item 13. If additional space is needed, MACs may submit with the completed CR Implementation report on a separate explanation document. Provide the following information in a clear and concise manner:
a. Cause of the delay; b. If not the entire CR, reference the specific delayed Business Requirements; c. Description of specific tasks that were delayed; d. Indicate what is the impact to the government and resolution of the issue that delayed the CR implementation; e. Note the actual implementation date of the CR requirements.
10. CRIR Totals. This section summarizes the totals for the detail rows.
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
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.
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.
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.
(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.
(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.
(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)
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.]
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.]
(Rev. 66, Issued: 01-07-11, Effective: 02-08-11, Implementation: 02-08-11)
(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.”
(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:
(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.
(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.
(Rev. 23, Issued: 05-06-05; Effective: 10-01-05; Implementation: 10-03-05)
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.
(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:
NOTE: The terms 'Active' & 'Inactive' are defined as:
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.
(Rev. 100, Issued: 06-23-16; Effective: 07-05-16; Implementation: 07-05-2016)
The Centers for Medicare & Medicaid Services' (CMS's) Division of Change Management (DCM) is responsible for the coordination and distribution of the draft Medicare Fee-for-Service (FFS) Change Requests (CRs) for Point-of-Contact (POC) Review. To that end, the DCM has developed the Electronic Change Information Management Portal (ECHIMP), a user-friendly, Web-based application to streamline and automate the change management process.
In September 2004, the initiators of the CRs began creating and submitting CRs to the DCM via ECHIMP. In the past, the DCM distributed the draft Medicare FFS CRs to only 15 contractor
POCs and shared system maintainers (SSMs) for POC review. The SSMs forwarded the CRs to their users for review which increased the time to market the CR and sometimes resulted in the submission of late comments. Therefore, beginning January 3, 2006, the DCM will continue to notify the CMS and SSM POCs of the draft Medicare FFS CRs that are in POC review and also notify all the Medicare FFS contractor POCs as well via ECHIMP 2.0. The DCM will implement ECHIMP 2.0 on a voluntary basis for its internal CMS staff. Initiators of CRs may create and submit a CR for POC review using ECHIMP 2.0 beginning January 3, 2006. However, effective February 6, 2006, ECHIMP 2.0 will be implemented on a mandatory basis (i.e., all CRs will be initiated, submitted and reviewed in ECHIMP 2.0). The POCs will continue to receive the POC Review e-mail for CRs initiated and submitted in ECHIMP 1.0 which will contain the CR and the attachments until February 6, 2006. In addition to receiving the POC review e-mail with the CR and the attachments, POCs will also receive the POC review e-mail alert for CRs that are initiated and submitted in ECHIMP 2.0 which will not contain the CR file and the attachments. However, these e-mail alerts will contain a link for the POCs to click to review and submit comments on the CR via ECHIMP 2.0.
NOTE: Beginning February 6, 2006, contractors and maintainers should not reply to any e-mails from ECHIMP@cms.hhs.gov nor should they send any e-mail to eChimp@cms.hhs.gov. Effective February 6, 2006, we will not accept any e-mails sent to that address.
The notification of the draft Medicare FFS CRs will be distributed via an E-mail from ECHIMP to the CMS, contractor and SSM POCs, which will no longer contain the files and documents associated with the draft CR. Once the POCs receive the e-mail notification from ECHIMP that notifies them that a CR is currently in POC review, they shall log in to ECHIMP via a link that will be provided in the E-mail notification. Once logged in, they shall review the draft CR and provide comments to CMS via ECHIMP by the POC Review Comment due date. To maintain as much efficiency as possible with such a large number of prospective reviewers, each POC may submit only one set of comments on behalf of their contractor or maintainer organization and that submission must be identified as such. If the CR impacts A/B MAC (A), A/B MAC (B), DME MAC and/or A/B MAC (HHH) and it makes more sense to submit the comments separately (to keep the content clear), then two sets of comments from the contractor site or maintainer organization will be acceptable. No response received will be considered a concurrence. NOTE: It is the responsibility of the POCs to notify appropriate staff that a CR has entered POC review and to share the information with them. Each individual who has access to ECHIMP will also have the ability to review, download and print the CR files and share the files, either electronically or hardcopy, with other staff members who do not have ECHIMP access.
We believe that expanding the POC review process to all of the Medicare FFS contractors and SSMs will not only decrease the time to market the CRs, but will also increase the quality of the review of the CRs by allowing a wider audience of those potentially impacted by the change the opportunity to comment. We also believe that this expansion to the POC review process will reduce the number of late comments submitted as well as reduce the number of corrected CRs now necessary as a result of uncoordinated and/or untimely POC comments.
CMS realizes that expanding the POC review process to all of the Medicare FFS contractors and SSMs could potentially cause a lack of efficiency and an administrative burden if the above-outlined POC review process is not adhered to. Therefore, we will pilot this expanded POC review process for approximately 3 months effective February 6, 2006. At the conclusion of the 3 months, we will evaluate the pilot and adjust the POC review process, if necessary.
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:
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.
(Rev.108, Issue: 11-03-17, Effective: 12-04-17, Implementation: 12-04-17)
Fee-for-Service contractor workload transitions occurred when a Medicare Administrative Contractor's (MAC's) period of performance ends or its contract is terminated. When either of these two circumstances occurs, the outgoing contractor is required to work with the new incoming contractor to transfer the Medicare workload without any disruption to providers and beneficiaries.
During a transition, the outgoing contractor has responsibilities and processes for closing out its Medicare contract and shutting down its operation. It must also assist the new incoming contractor in its efforts to assume the Medicare claims administration functions. Concurrently, the incoming contractor is required to establish an operational infrastructure and ensure that all data, records, and functions are properly transferred from the outgoing contractor. Both parties have a responsibility to ensure that the transition is conducted seamlessly and that all contractual obligations are met during the transition.
(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.
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.
| Rev # | Issue Date | Subject | Impl Date | CR# |
|---|---|---|---|---|
| R13175GI | 04/17/2025 | Internet Only Manual (IOM) Update, Publication (Pub.) 100-01, Chapter 7, 40.2 - General Information, Eligibility, and Entitlement Manual Chapter 7 - Contract Administrative Requirements | 05/19/2025 | 14038 |
| R11395GI | 05/04/2022 | Updated Instructions for the Change Request Implementation Report (CRIR) and Technical Direction Letter (TDL) Compliance Report (TCR) | 05/31/2022 | 12714 |
| R128GI | 11/01/2019 | Update to General Information, Eligibility, and Entitlement, Chapter 7 - Contract Administrative Requirements, Section 40.2 – Shared System Maintainer Responsibilities for Systems Releases | 12/03/2019 | 11518 |
| R125GI | 07/05/2019 | Internet Only Manual (IOM) - Update to General Information, Eligibility, and Entitlement, Chapter 7 - Contract Administrative Requirements, Section 40.2 – Shared System Maintainer Responsibilities for Systems Releases, Section 40.3.11 Single Testing Contractor (STC) Non-Testable Conditions and Potential Testing Impacts | 08/05/2019 | 11245 |
| R124GI | 05/17/2019 | Update to Publication (Pub.) 100-01 to Provide Language-Only Changes for the New Medicare Card Project | 06/18/2019 | 11240 |
| R122GI | 12/21/2018 | Updated Instructions for the Change Request Implementation Report (CRIR) and Technical Direction Letter (TDL) Compliance Report (TCR) | 05/28/2019 | 11067 |
| R108GI | 11/03/2017 | MAC Transition Workload Handbook | 12/04/2017 | 10329 |
| R105GI | 06/02/2017 | Update to General Information, Eligibility, and Entitlement, Chapter 7 - Contract Administrative Requirements, Section 40 – Shared System Maintainer Responsibilities for Systems Releases | 07/03/2017 | 10062 |
| R102GI | 11/02/2016 | Internet Only Manual (IOM) Publication 100-01 - General Information, Eligibility, and Entitlement, Chapter 7 - Contract Administrative Requirements, Section 40 – Shared System Maintainer Responsibilities for Systems Releases | 11/02/2016 | 9785 |
|---|---|---|---|---|
| R100GI | 06/23/2016 | Medicare Fee-for-Service Change Request Correction and Rescind Process | 07/05/2016 | 9455 |
| R99GI | 06/10/2016 | Medicare Fee-for-Service Change Request Correction and Rescind Process – Rescinded and replaced by Transmittal 100 | 06/10/2016 | 9455 |
| R97GI | 01/15/2016 | Internet Only Manual (IOM) Publication 100-01 - General Information, Eligibility, and Entitlement, Chapter 7 - Contract Administrative Requirements, Section 40 – Shared System Maintainer Responsibilities for Systems Releases | 09/21/2015 | 9219 |
| R95GI | 10/16/2015 | Internet Only Manual (IOM) Publication 100-01 - General Information, Eligibility, and Entitlement, Chapter 7 - Contract Administrative Requirements, Section 40 – Shared System Maintainer Responsibilities for Systems Releases – Rescinded and replaced by Transmittal 97 | 09/21/2015 | 9219 |
| R93GI | 08/21/2015 | Internet Only Manual (IOM) Publication 100-01 - General Information, Eligibility, and Entitlement, Chapter 7 - Contract Administrative Requirements, Section 40 – Shared System Maintainer Responsibilities for Systems Releases – Rescinded and replaced by Transmittal 95 | 09/21/2015 | 9219 |
| R90GI | 02/12/2015 | Rescinds/Replaces CR 7468 - Updated Instructions for the Change Request Implementation Report (CRIR) and Technical Direction Letter (TDL) Compliance Report (TCR) | 05/28/2015 | 8598 |
| R88GI | 08/25/2014 | Rescinds/Replaces CR 7468 - Updated Instructions for the Change Request Implementation Report (CRIR) and Technical Direction Letter (TDL) | 09/11/2014 | 8598 |
| Compliance Report (TCR) – Rescinded and replaced by Transmittal 90 | ||||
|---|---|---|---|---|
| R87GI | 08/08/2014 | Update to Pub. 100-01, Chapter 7 for Language-Only Changes for ICD-10 | Upon Implementation of ICD-10 | 8639 |
| R86GI | 05/16/2014 | Rescinds/Replaces CR 7468 - Updated Instructions for the Change Request Implementation Report (CRIR) and Technical Direction Letter (TDL) Compliance Report (TCR) – Rescinded and replaced by Transmittal 88 | 08/28/2014 | 8598 |
| R83GI | 03/07/2014 | Update to Pub. 100-01, Chapter 7 for Language-Only Changes for ICD-10 – Rescinded and replaced by Transmittal 87 | 10/01/2014 | 8639 |
| R75GI | 12/30/2011 | Contractor Implementation of Change Requests and Compliance With Technical Direction Letters – Rescinded and replaced by CR 8598 | 05/28/2012 | 7468 |
| R66GI | 01/07/2011 | Change Request (CR) Definitions | 02/08/2011 | 6592 |
| R59GI | 10/30/2009 | The CMS Standard File for Reason Codes for the Fiscal Intermediary Shared System (FISS) | 04/05/2010 | 6529 |
| R57GI | 02/20/2009 | Implementing Validated Workarounds for Share System Claims Processing by Medicare Administrative Contractors (A/B MACs), Durable Medical Equipment Medicare Administrative Contractors (DMEMACs). Carriers, Regional Home Health Intermediaries (RHHIs) and Fiscal Intermediaries | 03/20/2009 | 6379 |
| R54GI | 10/01/2008 | IDR Claims Sourcing From Shared Systems-Implementation | 01/05/2009 | 5949 |
| R53GI | 09/26/2008 | Medicare Contractor Testing with Future Dates in the EDC | 10/27/2008 | 6110 |
| R52GI | 07/11/2008 | Change to CR Implementation Report Due Dates | 08/11/2008 | 6102 |
| R51GI | 05/16/2008 | IDR Claims Sourcing From Shared Systems-Implementation - Rescinded and Replaced by Transmittal 54 | 10/06/2008 | 5949 |
| R46GI | 07/20/2007 | Implement New Contractor ID for Single Testing Contractor (STC) | 01/07/2008 | 5648 |
|---|---|---|---|---|
| R44GI | 05/25/2007 | Fee-for-Service Contractor Transition Handbooks | 07/02/2007 | 5446 |
| R43GI | 03/30/2007 | Clarification in Testing Instructions for Definition of “Local Components” | 07/02/2007 | 5395 |
| R38GI | 05/26/2006 | Files Maintenance Program Update to the Internet-Only Manual (IOM) | 06/26/2006 | 5055 |
| R34GI | 01/06/2006 | Change Management Process -- Electronic Change Information Management Portal (eChimp) | 01/03/2006 | 4092 |
| R33GI | 12/30/2005 | Change Management Process -- Electronic Change Information Management Portal (eChimp) | 01/03/2006 | 4092 |
| R30GI | 10/28/2005 | Initiate STC testing of the MCS for RRB and HIGLAS | 04/03/2006 | 4150 |
| R26GI | 07/22/2005 | Implement New Medicare Plan ID and Carrier Number for the Single Testing Contractor (STC) | 10/03/2005 | 3978 |
| R25GI | 07/15/2005 | Next Generation Desktop (NGD) Testing Requirements | 08/15/2005 | 3493 |
| R24GI | 05/27/2005 | 2005 Scheduled Release for July Updates to Software Programs and Pricing/Coding Files | 06/27/2005 | 3865 |
| R23GI | 05/06/2005 | Procedures for Modifying Shared Systems Edits and Capturing Audit Trail Data | 10/03/2005 | 3862 |
| R17GI | 02/25/2005 | Review of Contractor Implementation of Change Requests (Replacement for expired CR 944) | 03/01/2005 | 2884 |
| R16GI | 01/28/2005 | Standard Terminology for Claims Processing Systems | 04/04/2005 | 3596 |
| R15GI | 01/21/2005 | Review of Contractor Implementation of Change Requests (Replacement for expired CR 944) | 03/01/2005 | 2884 |
| R08GI | 07/30/2004 | Establish Standard Terminology for Medicare Shared Systems | 01/03/2005 | 3086 |
| R06GI | 05/2//2004 | CMS Policy for Testing Quarterly Release of the Medicare Shared Systems and the CWF | 08/01/2004 | 3011 |
|---|---|---|---|---|
| R05GI | 05/07/2004 | Initial Publication of Chapter | N/A | 2765 |
Back to top of Chapter