(General Information, Eligibility, and Entitlement Manual)

 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.   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).  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)   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.   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.   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.  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.