(General Information, Eligibility, and Entitlement Manual)

EXAM PLES:    ABENDS; inability to run a cycle or test    Inaccurate payment or no payment of claims (potentially significant impact)    Necessary file updates cannot be accomplished (payment files, history files)    Interface failures affecting test conditions   Priori ty 2 Classification   Production:   The problem adversely affects the accomplishment of a mission critical capability so as to degrade performance and for which no acceptable work- around is known.*  This means the problem adversely affects the payment of benefits with a small claim volume or  payment impact, the completion of CMS required reporting, or inaccurate information is being sent providers, beneficiaries or CMS.  For example, if the information on an outgoing document to the provider community or Medicare Summary Notice is incorrect, the issue would be classified as a priority 2.    EXAMPLES:    Inaccurate payment or no payment of claims (small impact/low volume)    Inaccurate CMS required report    Inaccurate messages to the beneficiary, provider or CMS    ABENDs with limited impact (e.g. one  contractor)   Beta/User Acceptance Testing:   The problem would adversely affect the accomplishment of a mission critical capability so as to degrade performance if current test software is moved into the production environment.  This means the problem adve rsely 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 outg oing document to the provider community is incorrect, the issue would be classified as a priority 2.    EXAMPLES:    Inaccurate payment or no payment of claims (potentially small impact)    Inaccurate CMS required report    Inaccurate messages to the beneficiary, provider or CMS     Priority 3 Classification   Production:   The problem adversely affects the accomplishment of mission critical capability so as to degrade performance and for which an acceptable workaround is known.*   This means the problem c ould have significant impact but the work- around alleviates the impact.  This allows the system maintainer adequate time to code a fix and sufficiently test before the corrected software is delivered for production installation.    EXAMPLES:    Impact of problem could be significant or minimal    Problem correctable by contractor workaround*    ABENDs with an acceptable workaround*   Beta/User Acceptance Testing:   The problem would adversely impact the accomplishment of a mission critical capability so as to degrade performance if current test software is moved into the production environment.  If moved into the production environment before correcting an acceptable workaround could be instituted to prevent the adverse impact. **  EXAMPLES:    Potential impact o f problem could be significant or minimal    Problem affects CMS required reporting   Priority 4 Classification   Production:   The problem is an operator inconvenience or annoyance, which does not affect a required mission essential capability.    EXAMPLES:    Problems affects non- mission critical functions    Operational procedure with workload impact that should be automated    Impact of problem is minimal   Correctable by contractor workaround*   Beta/User Acceptance Testing:   The problem is a test inconvenience or annoyance, which does not affect a required mission essential or test capability.  If moved into the production environment before correcting, an acceptable workaround could be instituted to prevent the inconvenience. **   EXAMPLES:    Problem affects non- mission critical functions    Operational procedure with workload impact that should be automated    Impact of problem is minimal   Correctable by contractor workaround*   Priority 5 Classification   Production:   All other doc umented system problems.  These could include operator errors, an inability to reproduce the reported problem, a problem with insufficient information, or documentation errors.  The system maintainer should request approval from the (GTL) before coding and implementing any system enhancements.   EXAMPLES:     A/B and DME MACs requested enhancements    Documentation errors    Problem affects non- mission critical functions    Minimal impact   Beta/User Acceptance Testing:   All other documented system test problems.  These could include operator errors, an inability to reproduce the reported problem, a problem with insufficient information, or test documentation errors.  The system maintainer should work to correct these issues as soon as possible but any system enhanc ements should be discussed with the GTL.   EXAMPLES:    Test region or processing enhancements    Test documentation    Problem affects non- mission critical test functions    Minimal impact  * An acceptable workaround is a temporary alternative solution to a confirmed problem in the shared system that will ensure the contractor is able to accomplish a mission critical capability.  What makes the workaround acceptable is it shall be agreeable to both the maintainer and contractor and does not cause an excessi ve 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 i nstitution of a workaround should be used in order to implement a CMS mandate where the system maintainer may not have time to adequately code a fix before the software is delivered for production installation.  40.2.1 - Implementing Validated Workarounds for Shared System Claims Processing by All Medicare DME MACs (Rev. 97, Issued: 01- 15-16, Effective: 09- 21-15, Implementation: 09- 21-15)  Medicare A/B, DME contractors shall implement workarounds within the shared systems for problems when formally defined as a Priority 3 or Priority 4 without obtaining written permission from a Project Officer or Regional Office.   Shared system problems that are formally defined as a Priority 3 or a Priority 4 have acceptable workarounds which provide temporarily alternative solutions.  In order for a A/B/DME MACs to implement a workaround, the shared system maintainer must first validate the problem, confirm that the workaround exists, is systematically viable and does not cause adverse effects.  The implementatio n 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 deacti vating standard edits.  The shared systems priorities are formally defined at Section 40.2 of this chapter.   40.3 - Shared System Testing Requirements for Shared System Maintainers, Single Testing Contractor (STC)/Beta Testers, and Medicare A/B, Durable Medical Equipment (DME) Administrative Contractors  (Rev. 97, Issued: 01- 15-16, Effective: 09- 21-15, Implementation: 09- 21-15)  Medicare requires implementation of a limited number of shared systems that must be used by all MACs for the administrative respon sibilities 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 quart erly 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 contra cts 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 wi ll 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 Railroa d Retirement Board (RRB) testing.  Three Medicare Contractor numbers have been established to accommodate STC testing.  They are 00888 for MCS systems testing, 00388 for FISS systems testing, and 44410 for DMEMAC systems testing.   This section identifies the testing responsibilities for each organization to ensure that each shared system quarterly release satisfies all CMS requirements.  All organizations shall have processes in place to meet these requirements.  Testing activities will generally begin 3 to  4 months in advance of the release date, particularly for shared system maintainers.   40.3.1  Shared System Testing Requirements for Shared System Maintainers, Single Testing Contractor (STC), and DME MACs (Rev. 97, Issued: 01- 15-16, Effective: 09- 21-15, Implementation: 09 -21-15)  Review subsection 40.3.9, Definitions, for a description of key testing terminology.   1. Maintainers  of a Shared System shall plan and execute all the essential levels of testing.  At a minimum this includes Unit testing, Integr ation 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 le vel, 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 c ases with future dates (e.g., service dates, admission dates) without turning off edits or altering effective dates in the test environment.   40.3.2  Minimum Testing Standards for Shared System Maintainers and the Single Testing Contractor (STC)/Beta Test ers (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, f or 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 t he Single Testing Contractor (STC) shall specifically:    Maintain a repository of test requirements against which all test cases must be traced.    Prepare and execute a set of test cases that demonstrate the requirements were correctly implemented for all ch ange requests within the quarterly release.    Maintain traceability between each test case and the requirement that the case was designed to test.   2. The Shared System Maintainers and Single Testing Contractor (STC) shall distinguish each test requirement with a unique Requirement Identifier.  The Requirement Identifier must be a number or qualifier preceded by the CMS CR number and SSM CR number, separated by dashes.  The format of the Requirement Identifier is: [SSM CR No.] -[CMS CR No.] -[Requirement No.], where:    SSM CR No.  is a number that identifies a CMS mandate or user change request under test. Free form text can also be used to identify changes not associated with maintainer CR numbers, e.g., Regression to indicate regression testing.  Avoid spac es and use underscore symbol _ instead.  Dashes not allowed within this number; they are reserved for separation between the individual numbers in the Requirement Identifier.    CMS CR No.  is a minimum 4 -digit number that identifies the CMS CR associated  with the maintainer CR number.  If no CMS CR is associated with a maintainer CR, use 0000.  Dashes are not allowed.  Avoid spaces and use underscore symbol _ instead.  Dashes not allowed within this number; they are reserved for separation between the  individual numbers in the Requirement Identifier.