evekhm/cms_iom_500 huggingface dataset:
(General Information, Eligibility, and Entitlement Manual)
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.   5. The CMS testing requirements outlined in section 40.3 may require the STC/beta tester to test a specific type of bill, specialty, or claim situation for which  they do not possess the required level of expertise.  In these instances, the STC/beta tester must partner with a Medicare A/B, DME MAC that possesses both the expertise and capabilities to test the specialty or claim type.  As an example, should the STC/ beta tester not have the operational capability or expertise to process Home Health claims, they are expected to partner with an A/B MAC (HHH)  to complete the required HHA testing.  Ultimately, the STC/beta tester is responsible for ensuring all test cases  are exercised.  Any partnerships that are established to complete the testing requirements shall be arranged and managed by the STC/beta tester.   40.3.4 - Testing Requirements Applicable to the CWF Beta Tester  (Rev. 43; Issued:  03- 30-07; Effective:  07- 01-07; Implementation:  07 -02-07)  The CWF Beta tester shall act as a test host and exchange data with entities testing the FISS, MCS, and VMS shared systems.  The testing entities include all shared system maintainers and  the shared system Beta t esters .  40.3.5  Part A/Part B (A/B) Durable Medical Equipment (DME) Medicare Administrative Contractor (MAC) (User) and the Single Testing Contractor (STC) Testing Requirements  (Rev. 97, Issued: 01- 15-16, Effective: 09- 21-15, Implementation: 09- 21-15)  A/B, DME MACs are not mandated to prepare and execute test cases that cover Medicare business requirements implemented within the base system in standard system and CWF quarterly releases.  Shared System Maintainers and the STC are fully responsible for testing  the base functionality.  The A/B, DME MAC (users) shall test their local/unique components and conduct a limited, end- to-end, operational test.
(General Information, Eligibility, and Entitlement Manual)
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 a ddition 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, facil ities, and tables in order to implement new Medicare policy or business rules.  Examples of these facilities include but are not limited to auto adjudication facilities (e.g., ECPS and MCS SCF) and the MCS SPITAB.   C. A/B, DME MAC shall fully test any shared system functionality that was:   - Developed by the shared system maintainer solely for them, or  - Developed by the shared system maintainer under a special project in which they were the exclusive participant.   An example would be a MAC working with CMS on a special demonstration project.  In this example the MAC shall fully test the shared system functionality that was implemented for the demonstration project.   2. A/B, DME MACs shall complete a limited end -to-end operational test that incorporates the shared sy stem 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 contig uous 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 MAC s 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:
(General Information, Eligibility, and Entitlement Manual)
A. A/B, DME MAC s shall ensure that the integrated systems software can complete cycles without system abends and produce the expected output.  The A/B, DME Medicare Contractor shall ensure their operational test:    Exercises all claims entry points not fully incorporated in the base system such as paper and EMC front -end components;    Includes all allowable standard electronic formats and versions;    Includes a variety of claims types; and    Includes all components that support their claims workload and interfaces to the shared system.   B. The operational test shall include the most recent shared system release received prior to the initiation of the test.  A/B, DME MACs shall initiate the test as required to ensure its completion and the reporting of any problem prior to production implementation.  3. CMS strongly encourages the shared system user community to promote:    Standardizing their system nationally,    Centralizing any table maintenance that implements national Medicare policy at the system maintainer level, and    Minimizing local variations.   4. A/B, DME MACs may perform additional testing on the shared system or duplicate Beta testing tasks as time permits.  At the discretion of their Regional Offices, the A/B, DME MACs may be required to separately document any testin g they perform in addition to their mandated testing.   5. A/B, DME MACs shall test any business rule or event with future dates that they code or set -up in their Auto Adjudication Software (AAS), prior to implementing the rule or event into production. Examples of AAS include but are not limited to ECPS, SCF, the Shack, and the Mill.   a. A/B MACS shall submit their date simulation recommendations to the FISS FWG in advance and participate in discussions at the FWG calls, as required to reach consensus on a date simulation schedule.   b. A/B MACS shall submit their date simulation recommendations to the MCS FWG in advance and participate in discussions at the FWG calls, as required to reach consensus on a date simulation schedule.   c. DME MACS shall submit their date simulation recommendations to the DMOP TAG or the CFMTAG in advance and participate in discussions at the TAG calls, as required to reach consensus on a date simulation schedule.
(General Information, Eligibility, and Entitlement Manual)
c. DME MACS shall submit their date simulation recommendations to the DMOP TAG or the CFMTAG in advance and participate in discussions at the TAG calls, as required to reach consensus on a date simulation schedule.   d. The FISS FWG, MCS FWG, and DMOP/CFM TAG shall use the system date request  process to provide the VDC(s) their latest run- date simulation schedule for their FISS, MCS, and VMS UAT environments.  e. The FWG or DMOP TAG shall maintain their run -date simulation schedule for a minimum of 14 calendars days in advance.  Here is an e xample 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.
(General Information, Eligibility, and Entitlement Manual)
f. The FISS FWG, MCS FWG, and DMOP/CFM  TAG shall provide a copy of their run-date simulation schedule to their CWF test host.   g. The FISS FWG and MCS FWG shall provide a copy of their run -date simulation schedule to the HIGLAS test site as required to accommodate their HIGLAS enabled contractors.   40.3.6 - Testing Requirements Applicable to all CWF Data Centers (Hosts)  (Rev. 97, Issued: 01- 15-16, Effective: 09- 21-15, Implementation: 09- 21-15)  Each CWF data center or CWF sector host shall:    Forward all satellite software and documentation to the satellites (contractors) to which they serve as the primary production host;    Install the CWF quarterly release software in a designated test region;    Make the designated test region available their satellites (users) for testing;    Coordinate test data , such as beneficiary data, with the user testers;    Process all satellite files submitted by the users and return all corresponding reply files generated for users;    Report release problems to the CWF Maintainer and CMS;    Verify with CMS that each of its satellites submitted at least one test file during user testing; and    The CWF Host shall support future date testing by the MACs.    The CWF Host shall review date simulation schedule submitted by the FISS FWG, MCS FWG, and DMOP TAG.   40.3.7 - Timeframe Requ irements for all Testing Entities  (Rev. 97, Issued: 01- 15-16, Effective: 09- 21-15, Implementation: 09- 21-15)  The SSMs, STC, and MAC shall operate under the testing timeframes shown below for each quarterly release:   Timeframe Requirements for Testing Enti ties   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.
(General Information, Eligibility, and Entitlement Manual)
 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 CW FM and SSM testing shall continue until Beta testing is initiated eight weeks prior to production implementation.  The SSM and CWFM shall complete a Unit Test (on all components), Integration Test, System Test, and Regression Test prior to distributing the  shared system release to the designated Beta tester.  For all integration, system, and regression testing, the SSM shall use the most recent version of any third party or CMS provided software components (e.g., Pricer, OCE, MCE, Grouper) they are provided.  The SSM shall continue testing beyond the exclusive maintainer -testing window due to the late receipt of some third party or CMS provided software components such as the Pricers and OCE.   40.3.8 - Testing Documentation Requirements (Rev. 97, Issued: 01- 15-16, Effective: 09- 21-15, Implementation: 09- 21-15)  1. The SSM, STC, and MAC shall maintain documentation that fully demonstrates the requirements of this transmittal were met for each quarterly release.  At a minimum the SSM, Beta tester, and MAC shall  maintain the following test documentation to demonstrate full compliance:    Test Requirement and Test Case repository with traceability;    Test Log;    Test Status for the execution (run) of each test case (i.e., Pass, Fail, Not Run);    Actual Results for the run of each test case in which the actual  results did not match the expected  results; and    Documented proof of each test run, i.e., screen shots, scheduler job logs, etc.  2. The SSM, STC, and MAC shall:    Maintain all test documentation for the four quarterly releases prior to the current release under test.  The documentation must be available for review by CMS (or its agent).    Document all software defects (problems) within the CMS specified repository such as INFOMAN.   3. The SSM shall communicate all confirmed software defects (problems) and fixes directly to CMS in writing through their CMS Maintenance Lead/(GTL) or other designee as specified by the CMS Project Officer.
(General Information, Eligibility, and Entitlement Manual)
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.
(General Information, Eligibility, and Entitlement Manual)
40.3.9 - Definitions (Rev.  105, Issued: 06 -02-17, Effective: 07- 03-17, Implementation: 07- 03-17) These definitions are provided to ensure common understanding.  Base Shared System  - The FISS, MCS, VMS, or CWF system, which is routinely released by the Shared System Maintainers to their respective user community prior to any user customization.  This includes all components released by the Shared System Maintainer, including but not  limited to the claim adjudication subsystem, the financial subsystems, and other integrated components (i.e., Pricer, OCE, MCE, Grouper).  Functional Testing   Testing to ensure that the functional requirements have been met. Functional testing is performe d 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 su bsystems 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 envi ronment. 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 applie s 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   Tes ting 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
(General Information, Eligibility, and Entitlement Manual)
accommodate production workloads. Performance Testing is performed by the STC.  Regression Testing   Tes ting 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 Te sting   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 r equired results associated with a specific test objective or purpose. Test Case Identifier   A unique identifier assigned to each test case.
(General Information, Eligibility, and Entitlement Manual)
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.  U nit testing may be both functional (requirements oriented) and structural (i.e. logic oriented, code coverage oriented). Unit testing is performed by the SSMs.   40.3.10 - Test Case Specification Standard  (Rev. 97, Issued: 01- 15-16, Effective: 09- 21-15, Im plementation: 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.
(General Information, Eligibility, and Entitlement Manual)
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 I dentifier 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 ste p starting at 1.  There is at least one test step in each test case specification, but usually contains multiple test steps.       Optional  Test Case  Elements  Step Description  A free form declarative statement that identifies the action taken to perform the  test.  The step description statement usually begins with a verb.
(General Information, Eligibility, and Entitlement Manual)
Optional  Test Case  Elements  Step Description  A free form declarative statement that identifies the action taken to perform the  test.  The step description statement usually begins with a verb.    Expected Step Results  A free form declarative statement that identifies the expected results from performing the associated step description.    Example #1   Test Case Identifier  4419 -2825 -5.2-001  Test Purpose  To confirm that the A/B MAC (A) claims processing systems accept, process, and assign reason code 30 (Payment adjusted because the patient has not met the required eligibility, spend down, waiting or residency requirements)  to Inpatient Hospital claims submitted on Type of bill (TOB) 111 (Hospital Inpatient Part A; admit through discharge) with Dates of Service (DOS) on 01/01/2004 when a beneficiary is not lawfully present in the United States.  Input Specification  Claims History  None  Beneficiary Information  Beneficiary must be unlawfully present in United States.  Beneficiary elected English as primary language  Provider Information  Provider Number Range = XX0001 -XX0999  Claim Data Requirements  TOB = 111  DOS = 01/01/2004   Intercase Dependencies  None   Output Specification  Claim will be assigned reason code 30 indicating beneficiary is not lawfully present in the United States, generating MSN message 5.7 (Medicare payment may not be made for the item or service because on the date of service, you were not lawfully present in the United States).   Test Type  P  Originator  C  Test Status  PS  Test Results  Claim was assigned appropriate reason code    40.3.11 - Single Testing Contractor (STC) Non -Testable Conditions and Potential Testing Impacts  (Rev. 125; Issued: 07- 05-19, Effective: 08- 05-19, Implementation: 08- 05-19)