evekhm/cms_iom_500 huggingface dataset:
(General Information, Eligibility, and Entitlement Manual)
 The effective date and implementation date are different because the f irst day of the quarter is not a Monday;    The effective date and the implementation date are different because the effective date occurs after the implementation date;   The effective date and the implementation date are different because the effective date occurs before the implementation date, but both dates are in the future; or    The effective date and the implementation date are different because the effective date occurs before the implementation date, and the effective date is in the past, while the implementation date is in the future.   50.4.3 - Effective Date  (Rev.  66, Issued: 01- 07-11, Effective: 02- 08-11, Implementation: 02- 08-11)   The effective date identified in a change request (CR) is the date on which any new rules, laws, processes and/or poli cies become active.   Beginning on this date, Medicare contractors shall apply the new rules to process Medicare claims according to their updated business processes and supporting technology.   The effective date is normally a mandated date resulting from l egislation or a regulation.  In the case of National Coverage Determinations (NCDs), the effective date is the first day the item or service that is the subject of the NCD is covered nationally under the Medicare Program.   Effective dates are not always fu ture dates; sometimes, they are in the past.  When this happens, the Centers for Medicare and Medicaid Services (CMS) instructs contractors, using business requirements, how to process claims for the period between the effective date and the implementation  date.  Typically, the effective date is the first day of any given fiscal year quarter or the first day of the month.  50.4.4 - Date of Service  (Rev.  66, Issued: 01- 07-11, Effective: 02- 08-11, Implementation: 02- 08-11)  The date of service (DOS)  is the date a provider renders service to a beneficiary. Unless otherwise specified, the effective date of a change request is the date of service.
(General Information, Eligibility, and Entitlement Manual)
The date of service (DOS)  is the date a provider renders service to a beneficiary. Unless otherwise specified, the effective date of a change request is the date of service.   For the purpose of processing claims, the effective  date for applying processing rules, laws, processes, and/or policies is the date the beneficiary received a service from a provider.  For Durable Medical Equipment (DME) claims with spanned dates of service, the ViPS Medicare System (VMS) will use only the From DOS as the date the supplier rendered a servic e to a beneficiary.  For example, if a new rule or law became effective on January 1, 2011, and a beneficiary received service on December 27, 2010, then that service would not  be covered under the new rule.  If the beneficiary received the service on or a fter January 1, 2011, then that service would be covered by the new rule.   More service- specific information on the Date of Service can be found in. Pub.100- 02, Medicare Benefit Policy Manual and Pub. 100- 04, Medicare Claims Processing Manual.   60 - Procedures for Modifying Shared System Edits and Capturing Audit Trail Data (Rev. 23, Issued:  05- 06-05; Effective:  10- 01-05; Implementation:  10- 03-05)  POLICY   Contractors must implement processes and procedures for adding, deleting, inactivating, bypassing or otherwise modifying all shared system edits.  Contractors must also have the capability to document and track those modifications.  Modifications to maintainer coded edits must additionally include documentation that provides the rationale for t he modification, the expected duration of the change, the impact of the change with respect to potential over or underpayments, claims volumes, effect on providers and / or beneficiaries, etc.  In addition, the claims operations manager or equivalent area manager must document approval of the edit modification followed by CMS approval before any maintainer coded edit change has been made.   MACs shall examine their current processes for modifying shared system edits and adjust them to incorporate the appropr iate levels of internal controls.  These controls must be documented and available upon request for review by CMS or an auditor.  In addition, contractors must limit the number of personnel with the security clearance to modify maintainer coded shared syst em edits to ten (10).
(General Information, Eligibility, and Entitlement Manual)
Should the reason for an edit modification be because of a shared system deficiency, that associated problem must be documented and reported to the maintainer by the contractor.  The shared system maintainer and contractor must prior itize the appropriate systems changes to correct edit deficiencies and schedule them for correction as soon as possible via existing change management processes.  Should there not be consensus with the contractors regarding schedule, CMS maintenance staff should be consulted.  Shared system maintainers must have the capability to track edit changes made by a contractor to the maintainer coded shared system edits.  The shared systems must be able to identify who modified the edit, what was modified and when the alteration was made.   60.1 - CMS Standard File for Reason Codes  (Rev. 59, Issued: 10- 30-09, Effective: 04- 01-10, Implementation: 04- 05-10)  The A/B MAC (A) or (HHH) Edits Evaluation Workgroup is tasked with identifying the inventory of contractor inactivated edits, documenting the reasons why the edits are turned off, and making a decision as to whether they should remain inactive or not.  Tra nsmittal 338, (Change Request (CR) 5927) issued on May 2, 2008, created the CMS Standard field within the existing FISS Reason Code File which contains the status that was determined by the A/B MAC (A) or (HHH) Edits Evaluation Workgroup for each individual code that was reviewed. The CMS Standard field indicators are as follows:    A = Active   I = Inactive     = Blank   NOTE:   The terms Active & Inactive are defined as:    Active = Reason code status is equal to S, P,   (blank), D, R, T, or is not equal to S MDLTD; and    Inactive = Reason code status is equal to A or is equal to S MDLTD.   Each quarter, as necessary, CMS will issue an updated CMS Standard File for Reason Codes which is loaded into the system by the FISS maintainer  via a Recurring Update Notification.   70 - Change Management Process -- Electronic Change Information Management Portal (ECHIMP)  (Rev. 100, Issued: 06- 23-16; Effective: 07- 05-16; Implementation: 07 -05-2016)
(General Information, Eligibility, and Entitlement Manual)
70 - Change Management Process -- Electronic Change Information Management Portal (ECHIMP)  (Rev. 100, Issued: 06- 23-16; Effective: 07- 05-16; Implementation: 07 -05-2016)   The Centers for Medicare & Medicaid Services (CMS s) Division of Change Management (DCM) is responsible for the coordination and distribution of the draft Medicare Fee -for-Service (FFS) Change Requests (CRs) for Point -of-Contact (POC) Review.  To that end, the DCM has developed the Electronic Change Infor mation Management Portal (ECHIMP), a user -friendly, Web -based application to streamline and automate the change management process.
(General Information, Eligibility, and Entitlement Manual)
In September 2004, the initiators of the CRs began creating and submitting CRs to the DCM via ECHIMP.  In the past, the DCM distributed the draft Medicare FFS CRs to only 15 contractor POCs and shared system maintainers (SSMs) for POC review.  The SSMs for warded the CRs to their users for review which increased the time to market the CR and sometimes resulted in the submission of late comments.  Therefore, beginning January 3, 2006, the DCM will continue to notify the CMS and SSM POCs of the draft Medicare FFS CRs that are in POC review and also notify all the Medicare FFS contractor POCs as well via ECHIMP 2.0.  The DCM will implement ECHIMP 2.0 on a voluntary basis for its internal CMS staff.  Initiators of CRs may create and submit a CR for POC review usi ng ECHIMP 2.0 beginning January 3, 2006.  However, effective February 6, 2006, ECHIMP 2.0 will be implemented on a mandatory basis (i.e., all CRs will be initiated, submitted and reviewed in ECHIMP 2.0).  The POCs will continue to receive the POC Review e- mail for CRs initiated and submitted in ECHIMP 1.0 which will contain the CR and the attachments until February 6, 2006.  In addition to receiving the POC review e -mail with the CR and the attachments, POCs will also receive the POC review e -mail alert for  CRs that are initiated and submitted in ECHIMP 2.0 which will not  contain the CR file and the attachments.  However, these e- mail alerts will contain a link for the POCs to click to review and submit comments on the CR via ECHIMP 2.0.  NOTE:   Beginning Fe bruary 6, 2006, contractors and maintainers should not  reply to any e -mails from  ECHIMP  @cms.hhs.gov nor should they send any e -mail to eChimp@cms.hhs.gov .  Effective Febr uary 6, 2006, we will not accept any e -mails sent to that address.
(General Information, Eligibility, and Entitlement Manual)
The notification of the draft Medicare FFS CRs will be distributed via an E -mail from ECHIMP to the CMS, contractor and SSM POCs, which will no longer contain the files and documents assoc iated with the draft CR.  Once the POCs receive the e- mail notification from ECHIMP that notifies them that a CR is currently in POC review, they shall log in to ECHIMP via a link that will be provided in the E -mail notification.  Once logged in, they shal l review the draft CR and provide comments to CMS via ECHIMP by the POC Review Comment due date.  To maintain as much efficiency as possible with such a large number of prospective reviewers, each POC may submit only one set of comments on behalf of their contractor or maintainer organization and that submission must be identified as such.  If the CR impacts A/B MAC (A), A/B MAC (B), DME MAC and/or A/B MAC (HHH) and it makes more sense to submit the comments separately (to keep the content clear), then two sets of comments from the contractor site or maintainer organization will be acceptable.  No response received will be considered a concurrence. NOTE:  It is the responsibility of the POCs to notify appropriate staff that a CR has entered POC review and to  share the information with them.  Each individual who has access to ECHIMP will also have the ability to review, download and print the CR files and share the files, either electronically or hardcopy, with other staff members who do not have ECHIMP access .  We believe that expanding the POC review process to all of the Medicare FFS contractors and SSMs will not only decrease the time to market the CRs, but will also increase the quality of the review of the CRs by allowing a wider audience of those potenti ally impacted by the change the opportunity to comment.  We also believe that this expansion to the POC review process will reduce the number of late comments submitted as well as reduce the number of corrected CRs now necessary as a result of uncoordinate d and/or untimely POC comments.
(General Information, Eligibility, and Entitlement Manual)
CMS realizes that expanding the POC review process to all of the Medicare FFS contractors and SSMs could potentially cause a lack of efficiency and an administrative burden if the above -outlined POC review process is not adhered to.  Therefore, we will pilot this expanded POC review process for approximately 3 months effective February 6, 2006.  At the conclusion of the 3 months, we will evaluate the pilot and adjust the POC review process, if necessary.   Change Request Corr ection and Rescind Process   Currently, the CR corrections and rescind process is a manual process, which is completed via email. CMS is automating the CR correction and rescind process utilizing the ECHIMP system. This CR implements the following processes :   CMS will begin distributing Medicare FFS CRs that are being corrected or rescinded for review via a notification from ECHIMP to the current POC Review recipients.  These notifications will specify the type of review to be performed in the subject line of the email (i.e., POC, Correction or Rescind Review).  All current POC Review recipients will receive the notifications whether they are impacted on the CR or not.  The notifications will specify which Medicare Administrative Contractors (MACs) and Shared  System Maintainers (SSMs) are impacted.    Impacted SSMs will review and comment on CRs during the CR's Correction or Rescind Review Period.    Impacted SSMs will update their estimates as a result of the correction or rescind.    Non-impacted SSMs and non- impa cted MACs will be able to review and comment on the draft corrected or draft rescinded CRs in ECHIMP, if they so choose.   CRs that have been corrected and rescinded prior to this automation will not be updated in ECHIMP.  This process will apply to CR corr ections and Rescinds initiated on or after July 5, 2016.
(General Information, Eligibility, and Entitlement Manual)
CRs that have been corrected and rescinded prior to this automation will not be updated in ECHIMP.  This process will apply to CR corr ections and Rescinds initiated on or after July 5, 2016.  80 - Contractor Workload Transitions  (Rev.108, Issue: 11- 03-17, Effective: 12- 04-17, Implementation: 12- 04-17) Fee-for-Service contractor workload transitions occurred when a Medicare Administrative  Contractors (MACs) period of performance ends or its contract is terminated.  When either of these two circumstances occurs, the outgoing contractor is required to work with the new incoming contractor to transfer the Medicare workload without any disruption to providers and beneficiaries.  During a transition, the outgoing contractor has responsibilities and processes for closing out its Medicare contract and shutting down its operation.  It must also assist the new incoming contractor in its efforts to assume the Medicare claims administration functions.  Concurrently, the incoming contractor is required to establish an operational infrastructure and ensure that all data, records, and functions are properly transferred from the outgoing contractor.  Both parties have a responsibility to ensure that the transition is conducted seamlessly and that all contractual obligations are met during the transition.   80.1 - Transition Handbooks  (Rev.108, Issue: 11- 03-17, Effective: 12- 04-17, Implementation: 12- 04-17) The Medicare Contractor Management Group (MCMG) in the Center for Medicare has developed a handbook in order to assist fee -for-service contractors with the transfer of Medicare workload from one contractor to another.  This is found at:  https://www.cms.gov /Medicare/Medicare- Contracting/Medicare -Administrative -Contractors/Resources -for-MACs.html  Every Medicare workload transition will vary depending on the unique circumstances and environment of the Medicare contractors involved.  There may be activities and processes described in the handbooks that, for various reasons, will not be applicable to a specific transition.  There may also be activities that will need to be performed that the handbooks do not cover.  The handbook cannot identify and address all of  the variations that may occur during a workload transition.  However, the overall activities described in the handbooks for managing a workload implementation or closeout project and the requirements contained therein for meetings, reporting, and providing information, data, and records are part of the IOM and incorporated by reference into the MAC contracts.
(General Information, Eligibility, and Entitlement Manual)
90 - Integrated Data Repository (IDR) Claims Sourcing from Shared Systems (Rev. 54, Issued:  10- 01-08; Effective:  10- 01-08; Implementation:  01- 05-09)  The CMS fraud investigation landscape is significantly different today than in the past as a result of program changes, such as the implementation of the Medicare Prescription Drug benefit, competitive selection of contractors responsible for claims administration and program integrity, such as Medicare Administrative Contractors (MACs) and PSCs, expansion of Medi -Medi and Recovery Audit Contractor (RAC) programs, and advent of the Medicaid Integrity Program (MIP).  CMS recognizes the need to signific antly enhance the use of technology to improve its collaborative fraud fighting efforts as well as to establish a modernized data analysis capability for all of Program Integrity.   Today, most Program Integrity contractors have built their own data warehouses and/or avenues for collecting, processing, analyzing data which serves their own individual needs.  These distributed, regional approaches to data analysis do not lend themselves to national analyses, do not represent best practices, and do not take advantage of the cost savings that a centralized data repository would provide.  All of these functions can be better served through a comprehensive set of common data structures and modern tools that encourage collaboration and innovation.  The IDR goal - through incremental releases -  is to be the centralized data repository for all Medicare data.  The Program Safeguard Contractors (PSCs) cannot currently use the IDR exclusively because the source of claims data is the National Claims History (NCH).  The li mited NCH data record is inadequate to support the extensive fraud, waste and abuse investigations that need to be performed by PSCs.  The Shared Systems data are the required data source for Program Integrity.  The CR initiates the acquisition of the Shar ed Systems data for the IDR.  Once the IDR has the required Shared Systems data, Program Integrity and their contractors will increase their ability to detect potential fraud, waste and abuse.
(General Information, Eligibility, and Entitlement Manual)
FISS shall provide, in electronic format, all claims output fo r all A/B MACs (A) or (HHH) and claim types on a daily basis at the claims header and detail level for each of the three identified lifecycle phases required.  MCS shall provide, in electronic format, all claims output for all A/B MACs (B)  and claim types on a daily basis at the claims header and detail level for each of the three identified lifecycle phases required.   VMS shall provide, in electronic format, all claims output for all DME MACs and Certificates of Medical Necessity, as required with certain claims for payment, on a daily basis at the claims header and detail level for each of the three lifecycle phases required.
(General Information, Eligibility, and Entitlement Manual)
The IDR Lifecycle Phase I is defined as the claim upon enumeration.  The IDR Lifecycle Phase II is defined as the claim immediately  after CWF adjudication.  The IDR Lifecycle Phase III is defined as the claim once financial information has been posted to it. Transmittals Issued for this Chapter  Rev #  Issue Date  Subject  Impl Date  CR#  R128GI  11/01/2019 Update to General Information, Eligibility, and Entitlement, Chapter 7 -  Contract Administrative Requirements, Section 40.2  Shared  System Maintainer Responsibilities for Systems Releases  12/03/2019 11518 R125GI  07/05/2019 Internet Only Manual (IOM) -  Update to General Informat ion, Eligibility, and Entitlement, Chapter 7 -  Contract Administrative Requirements, Section 40.2  Shared System Maintainer Responsibilities for Systems Releases, Section 40.3.11 Single Testing Contractor (STC) Non -Testable Conditions and Potential Testin g Impacts  08/05/2019 11245 R124GI  05/17/2019 Update to Publication (Pub.) 100- 01 to Provide Language -Only Changes for the New Medicare Card Project  06/18/2019 11240 R122GI  12/21/2018 Updated Instructions for the Change Request Implementation Report (CRIR) and Technical Direction Letter (TDL) Compliance Report (TCR)  05/28/2019 11067 R108GI  11/03/2017 MAC Transition Workload Handbook  12/04/2017 10329 R105GI  06/02/2017 Update to General Information, Eligibility, and Entitlement, Chapter 7 -  Contract Administrative Requirements, Section 40  Shared System Maintainer Responsibilities for Systems Releases
(General Information, Eligibility, and Entitlement Manual)
07/03/2017 10062 R102GI  11/02/2016 Internet Only Manual (IOM) Publication 100-01 - General Inf ormation, Eligibility, and Entitlement, Chapter 7 -  Contract Administrative Requirements, Section 40  Shared System Maintainer Responsibilities for Systems Releases  11/02/2016 9785 R100GI  06/23/2016 Medicare Fee- for-Service Change Request Correction and Rescind Process  07/05/2016 9455 R99GI  06/10/2016 Medicare Fee- for-Service Change Request Correction and Rescind Process   Rescinded and replaced by Transmittal 100 06/10/2016 9455 R97GI  01/15/2016 Internet Only Manual (IOM) Publication 100-01 - General Information, Eligibility, and Entitlement, Chapter 7 -  Contract Administrative Requirements, Section 40  Shared System Maintainer Responsibilities for Systems Releases  09/21/2015 9219 R95GI  10/16/2015 Internet Only Manual (IOM) Publication 100-01 - General Information, Eligibility, and Entitlement, Chapter 7 -  Contract Administrative Requirements, Section 40  Shared System Maintainer Responsibilities for Systems Releases   Rescinded and replaced by Transmittal 97  09/21/2015 9219 R93GI  08/21/2015 Internet Only Manual (IOM) Publication 100-01 - General Information, Eligibility, and Entitlement, Chapter 7 -  Contract Administrative Requirements, Section 40  Shared System Maintainer Responsibilities for Systems Releases   Rescinded and replaced by Transmittal 95  09/21/2015 9219 R90GI  02/12/2015 Rescinds/Replaces CR 7468 -  Updated Instructions for the Change Request Implementation Report (CRIR) and Technical Direction Letter (TDL) Compliance Report (TCR)  05/28/2015 8598 R88GI  08/25/2014 Rescinds/Replaces CR 7468 -  Updated Instructions for the Change Request Implementation Report (CRIR) and Technical Direction Letter (TDL) Compliance Report (TCR)   Rescinded and replaced by Transmittal 90  09/11/2014 8598 R87GI  08/08/2014 Update to Pub. 100- 01, Chapter 7 for Language -Only Cha nges for ICD -10 Upon Implementation of ICD -10 8639 R86GI  05/16/2014 Rescinds/Replaces CR 7468 -  Updated
(General Information, Eligibility, and Entitlement Manual)
Pub. 100- 01, Chapter 7 for Language -Only Cha nges for ICD -10 Upon Implementation of ICD -10 8639 R86GI  05/16/2014 Rescinds/Replaces CR 7468 -  Updated Instructions for the Change Request Implementation Report (CRIR) and Technical Direction Letter (TDL) 08/28/2014 8598 Compliance Report (TCR)  Rescinded and replaced by Transmittal 88  R83GI  03/07/2014 Update to Pub. 100- 01, Chapter 7 for Language -Only Changes for ICD -10  Rescinded and replaced by Transmittal 87  10/01/2014 8639 R75GI  12/30/2011 Contractor Implementation of Change Requests and Compliance With Technical Direction Letters  Rescinded and replaced by CR 8598 05/28/2012 7468 R66GI  01/07/2011 Change Request (CR) Definitions  02/08/2011 6592 R59GI  10/30/2009 The CMS Standard File for Reaso n Codes for the Fiscal Intermediary Shared System (FISS)  04/05/2010 6529 R57GI  02/20/2009 Implementing Validated Workarounds for Share System Claims Processing by Medicare Administrative Contractors (A/B MACs), Durable Medical Equipment Medicare Administrative Contractors (DMEMACs). Carriers, Regional Home Health Intermediaries (RHHIs) and Fiscal Intermediaries  03/20/2009 6379 R54GI  10/01/2008 IDR Claims Sourcing From Shared Systems -Implementation  01/05/2009 5949 R53GI  09/26/2008 Medicare Contractor Testing with Future Dates in the EDC  10/27/2008 6110 R52GI  07/11/2008 Change to CR Implementation Report Due Dates  08/11/2008 6102 R51GI  05/16/2008 IDR Claims Sourcing From Shared Systems -Implementation -  Rescinded and Replaced by Transmittal 54  10/06/2008 5949 R46GI  07/20/2007 Implement New Contractor ID for Single Testing Contractor (STC)  01/07/2008 5648 R44GI  05/25/2007 Fee-for-Service Contractor Transition Handbooks  07/02/2007 5446 R43GI  03/30/2007 Clarification in Testing Instructions for Definition of Local Components  07/02/2007 5395 R38GI