|
The purpose of this section page is to alert you to reporting issues and errors CMS has identified. We hope by providing you information, you will be able to avoid common mistakes and successfully participate in Section 111 reporting. REGISTRATION - Please determine the roles each individual will play prior to registering.
- Authorized Representatives cannot be users of the Section 111 COBSW for any RRE ID and may not obtain a Login ID.
- It is absolutely critical to provide information for your Authorized Representative during the New Registration step on the Section 111 Coordination of Benefits Secure Web site (COBSW) and Account Manager information during the Account Setup step. These must be two different individuals.
Please see the Section 111 User Guides and the "How To" documentation on the menu of the home page of the Section 111 COBSW for a description of the registration steps and user roles. ELECTRONIC DATA INTERCHANGE (EDI) ISSUES If you have a program or technical problem involving your Section 111 data exchange, the first person to contact is your assigned EDI Representative (EDI Rep) at the COBC. If you feel that your issue has not been resolved at this level, please follow the issue escalation process that is detailed in the User Guides. REPORTING New Information: The most efficient way to find or verify if an individual is a Medicare beneficiary is to query before sending an MSP or Claim Input File. When a record for an individual who is not a Medicare beneficiary is included on an MSP or Claim Input File, the COBC rejects the record with a disposition code of 51 or 55. To avoid this, we recommend using the Query Input File or the Non-MSP File (GHP only) to determine if the individual is a Medicare beneficiary. If this recommended process is followed, your volume of MSP or Claim Input File records rejected statistics will not be inflated by individuals not found to be Medicare beneficiaries. File statistics are available on the File Detail Page of the COB Secure Web site. (Please note that with any of the Medicare entitlement data verification methods, if the input record's matching criteria is incorrect, the individual will not be identified as a Medicare beneficiary. See the User Guides for more information on the matching criteria). Please Avoid These Common Errors File Submission - Retiree Records on MSP Input Files
Do not include Non-MSP records on the MSP Input File. For example: DO NOT include retiree records on the MSP Input File (with the exception of beneficiaries that are ESRD/MSP). Please notify your EDI Representative (EDI Rep) immediately if you become aware of any Non-MSP or retiree records included on an MSP Input File. Test files should contain real data. During the testing phase, please include records for Active Covered Individuals 65 years of age and older, thus assuring more "hits". Continued communication with your EDI Rep is critical to success. Contact your EDI Rep as soon as possible to initiate communication. Let your EDI Rep know when you are ready to submit test files or if there are any file submission issues. Deleting Records - Avoid Inappropriate Deletion of Records
Deletes should be used ONLY under the following circumstances: 1. To delete an entire record that was created in error. If an MSP record was mistakenly created and posted (you received an '01' disposition code in your MSP Response File), a Delete would be used to remove the record. In these cases the Delete is only used to remove a previously accepted record, not to change/update the record. Note: If a record was submitted in error but you never received an '01' disposition code, there is no need to submit a Delete for that record. 2. To correct one of the following key fields in a previously successfully added MSP record: - Effective Date - Insurance Coverage Type - Patient Relationship In these cases the Delete should be followed by an Add transaction containing the correct information. It has come to CMS' attention that some GHP RREs are submitting "deletes" for existing records and then submitting the same records as "adds" in the belief that this is necessary for the RRE to be compliant specifically for purposes of MMSEA Section 111. RREs should NOT delete existing records unless they are clearly erroneous, and must submit "updates" rather than "deletes" where appropriate. RREs put themselves and their employer clients at risk when they submit an unnecessary "delete" and subsequent "add" for an individual. CMS processes more than 1 billion claims per year. If records are unnecessarily deleted and then re-added, Medicare contractors could make mistaken payments during the brief time period between when the record is deleted and the record is re-added. This, in turn, would require recovery actions by CMS which are expensive for both CMS and employers as well as insurers/TPAs. If other information changes, (for example, Termination Date), follow standard Update procedures. New Information: FILE PROCESSING E-MAILS Currently, only the Account Manager and the Account Representative receive E-mails related to file processing (file receipt, late submission, threshold error). If you are an Account Designee and are in a position where you require or are interested in file status, processing or statistics, you may access this information on the COB Secure Web site. HICN/SSN Collection -Compliance The "HICN, SSN Collection - NGHP Model Language" and "HICN, SSN Collection - GHP Model Language", found on this Mandatory Insurer Reporting Web site, are supplied to assist GHP and NGHP Responsible Reporting Entities (RREs) in collecting HICNs and/or SSNs. RREs are not required to use the specific model language provided. However, if an RRE chooses to use their own language to collect the required information, and is unsuccessful, CMS may not consider that RRE to be compliant with Section 111 reporting requirements. Change in Reporting Status Any upcoming changes in an RRE ID's continued reporting status should be reported immediately to your EDI Rep. Examples of this might include a change in your agent, ceasing business operations, business merger, etc. Change in reporting status notifications should include written notice to the COBC. E-Mail Communications/SPAM Please ensure that e-mails from the COBC (COBVA at GHI.Medicare) are not sent to "spam" folders or "junk mail", for anyone associated with your RRE ID (e.g. Account Representative, Account Manager or Account Designee). This action could impact others' ability to receive Section 111 e-mails, disrupt the flow of communication from the COBC and weaken the RRE ID's reporting relationship with CMS.
Page Last Modified: 11/17/2009 4:24:27 PM
Help with File Formats and Plug-Ins
Submit Feedback
|
Email
Print