(General Information, Eligibility, and Entitlement Manual)

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)                                                                                           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 Runboo ks 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.       40.3.12 - Next Generation Desktop (NGD) Requirements  (Rev. 105 , Issued: 06 -02-17, Effective: 07- 03-17, Implementation: 07- 03-17) CMS has fully deployed the Next Generation Desktop (NGD) to the contractors beneficiary customer service contact centers.  The NGD is a multiple call center application that is used by Medicare Customer Service Representatives (CSRs) to answer inquiries and perform operations on behalf of CMS beneficiaries and the Amer ican 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, perio dic 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 re quired 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- speci fic 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 Standard s for Maintainers and Beta Testers, for NGD test case identifiers, the NGD maintainer should refer to the NGD System Test Plan.  4.  Section 40.3.7 Timeframe Requirements for Testing Entities  NGD testing timeframes are as follows:    The official NGD User A cceptance testing period conducted by the VCS Support Contractor shall begin 2 weeks prior to production implementation.  The overall NGD testing period shall begin 3 weeks prior to production implementation.   The NGD VCS Support testers shall have an exclu sive 1 week testing timeframe prior to the initiation of user testing (Validation testing)  -The User Acceptance tester shall complete a functional System Test and Regression Test before the system is released to the User community.   Exclusive NGD System Mai ntainer 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 distributi ng the shared system release to the designated Beta Tester.  5. Section 40.3.8 Testing Documentation Requirements (#2) For NGD, documentation of all software defects (problems) should be through ClearQuest.  50 - Contractor Implementation of Change Requests and Compliance with Technical Direction Letters  (Rev. 122, Issued: 12- 21-18, Effective: 05- 28-19 Begin with Quarter 2 report in 2019, Implementation: 05 -28-19 Begin with Quarter 2 report in 2019)   POLICY   Contractors shall implement all issued Change Requests (CRs) and comply with all issued Technical Direction Letters (TDLs).  Medicare Administrative Contractors (MACs) shall prepare and transmit the quarterly Contractor Implementation of Change Request (CR IR) 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 f ont.   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 s hall 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_REP ORTS@cms.hhs.gov .  NOTE:  There are no spaces in this email address. Underscore _ separates the words CR_IMPL_REPORTS.