Reporting Do's and Don'ts

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. The Authorized Representative may not be an agent.
• 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.
• Only the Authorized Representative may sign the Profile Report.
• The RRE, remains solely responsible and accountable for completing registration.  Agents are not permitted to initiate registration or sign the Profile Report.

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

Validating Addresses

RREs are encouraged pre-validate employer and insurer/TPA addresses prior to submitting in their TIN Reference Files.  Postal software and online tools are available on the United States Postal Service (USPS) website pages.  RREs should use standard abbreviations and adhere to USPS standards. The automated address validation enhancements effective October 2011 “scrub” addresses submitted on the TIN Reference File, using these USPS standards, to improve deliverability, but it is recommended that RREs also attempt to adhere to these standards, before they send their data file, in order to reduce errors and improve results.

(Note: Foreign Employer Addresses submitted with a TIN Indicator of “E”, “S” or “Z”, where the State Code in Field 6 equals “FC”, are not validated in this manner.)

Please Avoid These Common Errors         

File Submission 

GHP Only

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

• Submitting Records for Individuals Under 45 Years of Age

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. 

• Coverage Types A, J and K (Field 8)

If a beneficiary has an open Coverage Type A (Hospital and Medical), no additional records for Coverage types J (Hospital Only) or K (Medical Only) from the same insurer should be submitted. If the beneficiary no longer has Coverage Type A, but has subsequently acquired Coverage Type J or K, the record with Coverage Type A should be updated with a termination date, and then a new record should be added with the Coverage Type J or K.

• Insurer TINs (Updated)

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 an error code of "SPT1" for all records associated with the unmatched TIN.  The errors must be corrected immediately, and may not wait until the next quarterly submission.

An "SPT1" 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.

Please review your TIN Reference Response File to see why a TIN Reference Detail Record may have been rejected.  You may contact your EDI Representative for any additional information.

NGHP Only

• Invalid ICD-9 Diagnosis Code (starting at Field 19)

Codes supplied in an ICD-9 Diagnosis Code Field must exactly match the first 5 positions of a code on the list of valid ICD-9 diagnosis codes. (See Section 11.2.5 of the NGHP User Guide for a link to the list of codes considered valid for Section 111 reporting).

• Be sure to include any leading or trailing zeroes.
• Do not add a zero to a valid code.  For example, the valid code for lumbar sprain is 8472. It is not a valid code when reported as 08472 or 84720.

In certain publications, ICD-9 Diagnosis Codes are shown with decimal points. For Section 111 reporting, do not include a decimal point, but be sure to include any digits that may follow the decimal point.

In some cases, ICD-9 Diagnosis Codes contain 4 or 5 digits but RREs are reporting only 3 digits. For example, all ICD-9 Diagnosis Codes beginning with "389" must be reported with either 4 or 5 digits (e.g., 3898 or 38901).

Records with any of these invalid entries will be rejected with the errors CI05 – CI023, depending on the field(s) in error.

• Use of ‘NOINJ’ Cause of Injury and Diagnosis Code (Fields 15 and 19)

The ‘NOINJ’ code may only be used in very limited/specific circumstances.

The ‘NOINJ’ code is used where a settlement, judgment, award or other payment releases medicals or has the effect of releasing medicals, but the type of alleged incident typically has no associated medical care and the Medicare beneficiary/Injured Party has not alleged a situation involving medical care or a physical or mental injury. This is frequently the situation with a claim for “loss of consortium”, an “errors or omissions” liability insurance claim, a “directors and officers” liability insurance claim, or a claim resulting from a wrongful action related to employment status action is alleged.

‘NOINJ’ may not be submitted on claim reports reflecting ORM.

‘NOINJ’ should not be used as a default.  An RRE must perform its due diligence and report a proper and correct code.  Misuse of this code will put the RRE at risk for non-compliance.

Please refer to Section 11.2.5.1 in Version 3.3 of the NGHP User Guide for more information on the use of ‘NOINJ’.

• ORM Indicator (Field 98)/TPOC Threshold

As defined in Section 11.4 of the NGHP User Guide, liability and workers' compensation add records submitted with “N” in the ORM Indicator (Field 98) must contain TPOC Amounts that exceed the reporting thresholds. Records submitted with “N” in the ORM Indicator and zeroes in the TPOC Amount and TPOC Date Fields will be rejected with the CJ07 error.

• Reporting Multiple TPOCs

Section 11.5 of Version 3.3 of the NGHP User Guide provides information on how RREs are to report multiple TPOCs (Dates and Amounts) on the Claim Input File.  Remember that a TPOC is a single payment obligation reported in total regardless of whether it is funded through a single payment, an annuity or a structured settlement.  Multiple TPOCs are reported only when an RRE negotiates separate, different settlements at different times for a liability claim.  These are not common.   Please review the following tips:

• If multiple checks for a single settlement are issued on the same date, do not report each check as a separate TPOC; instead, combine the amounts and enter that sum in the ‘TPOC Amount 1’ field.  
• The dates in the ‘TPOC Date’ fields in the Claim Input Detail Record and the Claim Input Auxiliary Record should not be identical.  If they are then this is a single TPOC, and not multiple TPOCs.
• The date in the ‘Funding Delayed Beyond TPOC Start Date’ fields should never be the same as the date in the ‘TPOC Date’ fields.
• Contact your EDI Representative for assistance if you are unsure if your settlement is a multiple TPOC, or about how to report multiple TPOCs

• Policy Number (Field 74)

This is a required field and must contain the policy number of the insured associated with the underlying claim. In the case of self-insurance, if the RRE has no policy number associated with the claim, this field must be filled with all zeroes. Records submitted with all spaces in the Policy Number Field will be rejected with error CP04.

• Self-Insured Type (Field 65)

The value submitted in this field depends in part on what is supplied in the Self-Insured Indicator (Field 64). If “Y” is submitted as the Self-Insured Indicator, then a value of “I” or “O” must be submitted in the Self-Insured Type Field. If “N” is submitted as the Self-Insured Indicator, then a space must be submitted in the Self-Insured Type Field.  Records submitted incorrectly will be rejected with an error CS02.

• Liability Records/ORM Indicator (Fields 71 and 98)

Please ensure that Plan Insurance Type is entered correctly, when the RRE is assuming Ongoing Responsibility for Medicals (ORM).  Analyses of early reporters' files have identified numerous records where an RRE is mistakenly reporting Liability with an ORM indicator of “Y”.  Assuming ORM in Liability cases is not a common occurrence.

We have also identified instances where the Plan Insurance Type was correct but the RRE mistakenly reported ORM.

While there are instances where this combination may be correct, RREs should review their information to be certain they have provided the correct data.

• No-Fault Insurance Limit (Field 81)

The No-Fault Insurance limit should be entered in Field 21 with the decimal implied.  This means the last 2 digits of the 11 fill numeric entry reflect cents.  For example, a No-Fault limit of 500 dollars and no cents must be submitted as ‘00000050000”.

The field may not be blank and must contain a valid numeric amount, all zeroes or all 9’s, as specified in the description for Field 81 in Appendix A, Version 3.3 of the NGHP User Guide.  Do not fill field with a combined entry of 0’s and 9’s unless you are entering a valid no-fault limit.

GHP and NGHP

• Disposition Code 51

RREs will receive this disposition code on their response files if the information submitted for an individual is not matched to information CMS has on file for Medicare beneficiaries.  In most cases this is because the individual is not a Medicare beneficiary.  But there are other reasons that we may be unable to match the submitted information to a Medicare beneficiary.  These can include: no valid HICN or SSN is provided on the input record; errors in any of the fields; and data in the wrong fields (e.g., Last Name in the First Name field).  Please review all records that receive a Disposition 51 very carefully to ensure your submission was correct.  If you find any errors, please correct them and submit the corrected record on your next scheduled file submission.

• Bad Test Data

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

• Lack of Communication

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.