evekhm/cms_iom_500 huggingface dataset:
(General Information, Eligibility, and Entitlement Manual)
 Inaccurate pay ment or no payment of claims (significant impact/high volume)    Necessary file updates cannot be accomplished (payment files, history files)    Interface failures affecting claims processing   Beta/User Acceptance Testing:   The problem would prevent the accomplishment of a mission critical capability if the current test software is moved into the production environment.  This priority also includes problems where code shall  be fixed immediately in order for the normal test region functions or services to continue.  For example, if the test region is down in a job causing the cycle to not complete or the system is pricing claims incorrectly with a potentially significant claim volume or payment impact, the issue would be classified as a priority 1.     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:
(General Information, Eligibility, and Entitlement Manual)
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:
(General Information, Eligibility, and Entitlement Manual)
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.
(General Information, Eligibility, and Entitlement Manual)
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.
(General Information, Eligibility, and Entitlement Manual)
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.
(General Information, Eligibility, and Entitlement Manual)
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:
(General Information, Eligibility, and Entitlement Manual)
 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.    Requirement No.  is a number that uniquely identifies the requirement with the CR.  For any requirement taken from the Business Requirements section of a CMS CR, use the actual number from the Requirement # column.  Do not repeat the CMS CR number.  Dashes not allowed within this number; they are reserved for separation between the individual numbers in the Requirement Identifier.   Example:  Maintainer CR 22522 corresponds to CMS CR 2634.  Business Requirement 2.8 was taken directly from CMS CR 2634.  The Requirement Identifier would be 22522-2634- 2.8.  3. The Shared System Maintainer and the Single Testing Contractor (STC) shall complete Test Case specifications that include specific input situa tions and the expected results associated with a single test purpose.  Each test case specification must include the following:    A unique Test Case Identifier (which includes a cross -reference to the requirement in which the case is designed to test);    The specific objective or purpose of the case;    Input specifications (i.e., a description of the input situation[s]);    Output specifications (i.e., a description of the expected results); and    Intercase dependencies -  in instances where the test results of on e test case may impact other test cases, the test case specification must identify the other test case(s) and describe the relationship(s).
(General Information, Eligibility, and Entitlement Manual)
 Intercase dependencies -  in instances where the test results of on e 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 main tain test cases.   4. All Test Cases must contain a unique Test Case Identifier.  The CMS standard for the Test Case Identifier is the Requirement Identifier, followed by a number that uniquely qualifies the test case specification, separated by a dash.   The format of the Test Case Identifier is:  [Requirement Identifier] -[Test Case Number], where:    Requirement Identifier  is the actual identifier of the requirement being testing by the case.    Test Case Number  is a number that uniquely qualifies the tes t case.  This is generally a sequential number.  This is necessary since more than one test case is often needed to test a single requirement.   Dashes not allowed within this number; they are reserved for separation between the individual numbers in the T est Case Identifier.   Example:  Two test cases were developed to test the implementation of Requirement 22522- 2634- 2.8 (see example above).  The unique  Test Case Identifier for the two test cases would be 22522 -2634- 2.8-01 and 22522- 2634- 2.8-02.  5. The Sh ared 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 da tes in July or later and validate that the actual mandate was correctly implemented.
(General Information, Eligibility, and Entitlement Manual)
 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 serv ices 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 with in 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 element s 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 tes t 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 Cont ractor (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 S SMs and STC shall validate that their system can accept and correctly process all  input files.
(General Information, Eligibility, and Entitlement Manual)
 The Shared System Maintainers and the Single Testing Contractor (STC) shall validate that all  output files are correctly created by their system.  The S SMs and STC shall validate that their system can accept and correctly process all  input files.    The Shared System Maintainers and the Single Testing Contractor (STC) shall perform interface testing that includes full data exchanges (both ways) between the shared system and any principal claims processing adjudication or financial system (e.g., the CWF and HIGLAS respectively).  The STC is required to perform data exchanges with HIGLAS after HIGLAS is implemented at the STCs data center.    The Shared System Maintainers and the Single Testing Contractor (STC) shall complete an integrated system test coordinating the maintenance of test data baselines, such as beneficiary data, with the CWF Beta tester.   40.3.3  Testing Standards Applicable to all Beta Testers  (Rev. 97, Issued: 01- 15-16, Effective: 09- 21-15, Implementation: 09- 21-15)  1. Each shared system maintainer and each beta t ester shall complete integrated testing with the CWF Beta tester, using coordinated beneficiary data, in the execution of their tes t 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 pr ocedures 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 respo nse times, throughput rates, and processing windows and can accommodate production workloads.