evekhm/cms_iom_500 huggingface dataset:
(General Information, Eligibility, and Entitlement Manual)
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
(General Information, Eligibility, and Entitlement Manual)
 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
(General Information, Eligibility, and Entitlement Manual)
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.
(General Information, Eligibility, and Entitlement Manual)
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
(General Information, Eligibility, and Entitlement Manual)
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:
(General Information, Eligibility, and Entitlement Manual)
 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.
(General Information, Eligibility, and Entitlement Manual)
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.   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 d ue 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 1 includes October, November, and December. The report for Quarter 1 is due no later than February 28th.    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.    Quarter 4 includes July, August, and September. The report for Quarter 4 is due no later than November 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 sho uld 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 contractors 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).
(General Information, Eligibility, and Entitlement Manual)
Contractors shall retain the written documentation to  verify CR and TDL implementation/compliance using CMSs 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 impleme ntation/compliance to CMS.   Implementation Date   I. Definition   Refer to section 50.4.2 of this chapter for the definition of the implementation date.   II. Supporting Information  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 instructions 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 sh all comply with the revised instruction as soon as possible but no later than 10 business days from the CRs date of issuance.   For a system change, the Initiator of the CR will specify an implementation date that corresponds to one of the quarterly releas e 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/o r the Administrator.  This exception tends to occur most frequently with the implementation of National Coverage Determinations (NCDs) and corrections to finals.
(General Information, Eligibility, and Entitlement Manual)
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 addres sed 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.  COMPLETING AND SUBMITTING THE QUARTERLY CR IMPLEMENTATION REPORT (CRIR)   Medicare Administrative Contractors (MACs) shall complete the CR Implementation Report, as follows, for each jurisdiction. MACs wi th 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.   Header Rows   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 Juris diction 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.]
(General Information, Eligibility, and Entitlement Manual)
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 conta ct to ask questions regarding information in this report.  Contact must be knowledgeable on the contents of the report.   Details Rows   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 inc luded 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 complete this field with the CMS CR transmittal numbers implemented during the quarter.  If a CR was issued with multiple transmittals, the word multiple will be entered in 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 (A pplicable 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.
(General Information, Eligibility, and Entitlement Manual)
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 impl ementation 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 s hall 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. MLN delay  04. CMS delay of file transmiss ion 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.