|
The purpose of this section page is to alert you to reporting issues and errors CMS has identified. We hope by providing you this information, you will be able to avoid common mistakes and successfully participate in Section 111 reporting. REGISTRATION - Please determine the role 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 Verifying Beneficiaries: 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. 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. Individuals under age 45 are only to be reported on your MSP Input File if they are known to be entitled to Medicare, and have coverage in the plan based on their own or a family member's current employment status. If you are including any individuals under age 45 on your file, please ensure you supply the Health Insurance Claim Number (HICN) for each. Records for individuals under 45, submitted without the HICN, will be rejected with an 'SP99' error and not matched to Medicare beneficiary data. (No HICN will be returned). If you do not have the HICN for a known Medicare beneficiary, you may obtain it directly from the covered individual using the Model Language provided on the MIR Web site. Alternatively, you may submit a query record on the Query Input File, which includes the necessary matching data, including Social Security Number, for that individual. Every Insurer/TPA TIN submitted in Field 22 of the MSP Input File must have a matching TIN Reference File Detail Record, with a TIN Indicator of "I" (Field 8), on the TIN Reference File. The "I" is used to indicate that the TIN record is for an insurer/TPA, and not an employer. If there is no matching "I" record, the MSP Response File will be returned with a disposition code of "SP" and an error code of "SP 25" for all records associated with the unmatched TIN. The errors must be corrected immediately, and may not wait until the next quarterly submission. An "SP 25" error will also be returned on the MSP Response File if a corresponding TIN Reference File Detail Record was rejected for any errors in the Insurer Name or Address fields. Contact your EDI Representative to discuss any records rejected due to TIN related errors. Test files should contain real data. During the testing phase, GHP RREs should include records for Active Covered Individuals 65 years of age and older, thus assuring more "hits". NGHP RREs should either use actual data for known Medicare beneficiaries or make use of the "Test Beneficiary Data for NGHP RREs" files that can be found under the Reference Materials menu option on the Section 111 COB Secure Web site (COBSW). 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 Input File record or Claim Input File record was mistakenly submitted and accepted (you received an '01' disposition code in your MSP Response File, or an '01' or '02' disposition code in your Claim 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 for it on your MSP Input File, or an '01' or '02' disposition code for it on your Claim Response File, 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 Input File record: - HICN/SSN (See Note)
- Effective Date
- Insurance Coverage Type
- Patient Relationship
or To correct one of the following key fields in a previously successfully added Claim Input File record: - Injured Party HICN or SSN (See Note)
- CMS Date of Incident
- Plan Insurance Type
- ORM Indicator
In these cases the Delete should be followed by an Add transaction containing the correct information. NOTE: RREs only need to correct the HICN/SSN in cases where an incorrect person was submitted and accepted on the input record. HICNs and SSNs may be reassigned by SSA at times but the COBC is able to crosswalk the old numbers to new numbers. Therefore in those instances where the correct person was previously submitted and the HICN or SSN changes for that person at a later date, the RRE should not send a delete to correct the record. If a record was previously submitted and accepted with only a SSN, and the RRE obtains the HICN on the Response file, the RRE should not send a "Delete" and "Add" to update the bene's information with the HICN. The record has already been stored under both the SSN and HICN by the COBC. Subsequent transactions for the record may be submitted with either the SSN or HICN. If other information changes, (for example, Termination Date), follow standard Update procedures. 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 @cms.hhs.gov, @ghimedicare.com and @ehmedicare.com addresses 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 other's ability to receive Section 111 e-mails, disrupt the flow of communication from the COBC and CMS and weaken the RRE ID's reporting relationship with CMS. Changes in Your Contact Information Please make sure any changes in the contact information that you provided for your Authorized Representative and Account Manager (s) are forwarded to the COBC's EDI Department on a timely basis. This includes contact name, address, phone number, and E-mail address. Your EDI Representative must have current contact information in order to keep you informed of any issues that may affect your RRE file submissions and your ongoing compliance with Section 111 reporting.
Page Last Modified: 08/23/2010 10:47:41 AM
Help with File Formats and Plug-Ins
Submit Feedback
|
Email
Print