MMSEA Section 111

MSP Mandatory Reporting

GHP User Guide

Version 5.9

Rev. 2020/ 10 November

COBR- Q4-2020-v5.9
GHP User Guide Confidentiality Statement

Confidentiality Statement
The collection of this information is authorized by Section 1862(b) of the Social Security Act
(codified at 42 U.S.C 1395y(b)) (see also 42, C.F.R. 411.24). The information collected will be
used to identify and recover past conditional and mistaken Medicare primary payments and to
prevent Medicare from making mistaken payments in the future for those Medicare Secondary
Payer situations that continue to exist. The Privacy Act (5 U.S.C. 552a(b)), as amended, prohibits
the disclosure of information maintained by the Centers for Medicare & Medicaid Services
(CMS) in a system of records to third parties, unless the beneficiary provides a written request or
explicit written consent/authorization for a party to receive such information. Where the
beneficiary provides written consent/proof of representation, CMS will permit authorized parties
to access requisite information.
GHP User Guide PRA Disclosure Statement

Paperwork Reduction Act (PRA) Disclosure Statement

According to the Paperwork Reduction Act of 1995, no persons are required to respond to a
collection of information unless it displays a valid Office of Management and Budget (OMB)
control number. The valid OMB control number for this information collection is 0938-1074
(Expires 04/30/2021). The time required to complete this information collection is estimated to
average 5.6 minutes per response, including the time to review instructions, search existing data
resources, gather the data needed, and complete and review the information collection. If you
have comments concerning the accuracy of the time estimate(s) or suggestions for improving this
form, please write to:
CMS
7500 Security Boulevard
Attn: PRA Reports Clearance Officer
Mail Stop C4-26-05
Baltimore, Maryland 21244-1850
CMS Disclosure
Please do not send applications, claims, payments, medical records or any documents
containing sensitive information to the PRA Reports Clearance Office. Please note that any
correspondence not pertaining to the information collection burden approved under the
associated OMB control number listed on this form will not be reviewed, forwarded, or
retained.
If you have questions or concerns regarding where to submit your data, please contact CMS’
Benefit Coordination & Recovery Contractor (BCRC) by telephone or mail. The BCRC
Customer Service Representatives are available to assist you Monday through Friday, from 8:00
a.m. to 8:00 p.m., Eastern Time, except holidays, at toll-free lines: 1-855-798-2627 (TTY/TDD:
1-855-797-2627 for the hearing and speech impaired). For written correspondence, please use the
following address:
Medicare - Data Collections
P.O. Box 138897
Oklahoma City, OK 73113-8897
GHP User Guide Table of Contents

Table of Contents
Chapter 1 : Summary of Version 5.9 Updates ....................................................... 1-1
Chapter 2 : Introduction.......................................................................................... 2-1
Chapter 3 : MMSEA Section 111 Overview ........................................................... 3-1
Chapter 4 : Medicare Entitlement, Eligibility, and Enrollment ............................ 4-1
Chapter 5 : MSP Overview for GHP ....................................................................... 5-1
Chapter 6 : The GHP Reporting Process ............................................................... 6-1
6.1 Overview .................................................................................................................. 6-1
6.2 GHP Reporting Options............................................................................................ 6-2
6.2.1 Basic Reporting Option................................................................................. 6-2
6.2.2 Expanded Reporting Option ......................................................................... 6-3
Chapter 7 : GHP Mandatory Reporting Requirements ......................................... 7-1
7.1 General Reporting Requirements............................................................................. 7-1
7.1.1 Responsible Reporting Entities .................................................................... 7-1
7.1.1.1 Who Must Report ........................................................................... 7-1
7.1.1.2 Use of Agents ................................................................................ 7-1
7.1.2 Active Covered Individuals ........................................................................... 7-1
7.1.2.1 Finder File Approach to Determining Whom to Report .................. 7-4
7.1.3 Inactive Covered Individuals......................................................................... 7-5
7.1.4 File Format ................................................................................................... 7-5
7.1.5 Data Formatting Standards .......................................................................... 7-5
7.1.6 Section 111 Registration .............................................................................. 7-7
7.1.6.1 Overview ........................................................................................ 7-7
7.1.6.2 Registration and Account Setup Process ...................................... 7-8
7.1.6.3 Changes to RRE Registration and Reporting .............................. 7-13
7.1.7 File Submission Timeframes ...................................................................... 7-14
7.2 MSP Input File Requirements ................................................................................ 7-15
7.2.1 Overview..................................................................................................... 7-15
7.2.2 TIN Reference File ..................................................................................... 7-16
7.2.2.1 TIN Validation .............................................................................. 7-19
7.2.2.2 Address Validation and TIN Reference Response File................ 7-20
7.2.3 Record Matching Criteria ............................................................................ 7-23
7.2.3.1 Individuals .................................................................................... 7-23
7.2.4 Small Employer Exception (SEE) ............................................................... 7-24
7.2.5 Initial MSP Input File Submission ............................................................... 7-26
7.2.6 Quarterly Update MSP Input File Submissions .......................................... 7-27
7.2.6.1 Add, Delete, Update Transactions ............................................... 7-27
7.2.6.2 Quarterly Update Event Table ..................................................... 7-32
7.2.6.3 MSP Input File Reporting Helpful Reminders .............................. 7-35

i
GHP User Guide Chapter 2: Introduction

7.2.7 MSP Input File Detailed Requirements ...................................................... 7-36

7.2.7.1 MSP Initial Input Files .................................................................. 7-36
7.2.7.2 MSP Subsequent Quarterly Input Files ....................................... 7-36
7.2.7.3 About FSAs, HSAs, and HRAs .................................................... 7-38
7.2.8 Processing MSP Response Files ............................................................... 7-40
7.2.8.1 Disposition Codes ........................................................................ 7-41
7.2.8.2 SP Error Codes ............................................................................ 7-42
7.2.8.3 Rx Disposition and Rx Error Codes ............................................. 7-44
7.2.8.4 Part D Eligibility and Enrollment Data .......................................... 7-46
7.2.8.5 MSP Input File Threshold and Severe Errors .............................. 7-46
7.2.8.6 Late Submission Indicator ........................................................... 7-49
7.2.8.7 Split Entitlement Indicator – Multiple Response Records ............ 7-50
7.2.8.8 End Stage Renal Disease (ESRD) .............................................. 7-51
7.2.9 MSP Hierarchy Requirements .................................................................... 7-52
7.2.9.1 Background .................................................................................. 7-52
7.2.9.2 Hierarchy Requirements .............................................................. 7-53
7.2.9.3 Processing Records using Hierarchy Requirements ................... 7-54
7.2.9.4 Effect of Hierarchy Requirements on RRE submissions ............. 7-55
7.2.9.5 Hierarchy Override Code ............................................................. 7-56
7.2.10 Unsolicited Response File .......................................................................... 7-57
7.2.10.1 Overview ...................................................................................... 7-57
7.2.10.2 Benefits ........................................................................................ 7-57
7.2.10.3 RRE Enrollment and Termination ................................................ 7-58
7.2.10.4 Interested Party Table ................................................................. 7-58
7.2.10.5 File Creation and Transmission ................................................... 7-59
7.2.10.6 Unsolicited MSP Response File Records .................................... 7-60
7.2.10.7 Using the Unsolicited MSP Response File .................................. 7-62
7.2.10.8 Hierarchy Override Code Usage .................................................. 7-62
7.3 Query Only Input File Requirements ...................................................................... 7-63
7.3.1 Overview..................................................................................................... 7-63
7.3.2 Query Only Input File Detailed Requirements ............................................ 7-65
7.3.3 HEW Software Processing Environment Requirements ............................. 7-66
7.3.4 Query Files and HEW Software Requirements .......................................... 7-66
7.4 Non-MSP Input File Requirements......................................................................... 7-67
7.4.1 Overview..................................................................................................... 7-67
7.4.2 Action Types ............................................................................................... 7-68
7.4.2.1 N – Query Records ...................................................................... 7-68
7.4.2.2 D – Supplemental Prescription Drug Coverage Records ............ 7-68
7.4.2.3 S – RDS Retiree File Records ..................................................... 7-68
7.4.3 Record Matching Criteria ............................................................................ 7-68
7.4.3.1 Individuals .................................................................................... 7-68
7.4.3.2 Supplemental Prescription Drug Records .................................... 7-69
7.4.4 Initial Non-MSP Input File Submission ....................................................... 7-69

ii
GHP User Guide Chapter 2: Introduction

7.4.5 Update Non-MSP Input File Submissions .................................................. 7-71

7.4.5.1 Add, Delete, Update Transactions ............................................... 7-71
7.4.6 Detailed Non-MSP Input File Requirements............................................... 7-73
7.4.7 Processing Response Files ........................................................................ 7-74
7.4.7.1 Part D Eligibility and Enrollment Data .......................................... 7-74
7.4.7.2 Processing “D” Response Records ............................................. 7-75
7.4.7.3 Processing “N” Response Records ............................................. 7-76
7.4.7.4 Processing “S” Response Records .............................................. 7-76
7.4.7.5 Non-MSP Input File Threshold and Severe Errors ...................... 7-76
7.4.7.6 End Stage Renal Disease (ESRD) .............................................. 7-79
7.4.8 True-Out-of-Pocket (TrOOP) Facilitation RxBIN and PCN Codes ............. 7-79
7.4.9 RDS Retiree File Submission ..................................................................... 7-80
7.5 Testing the Section 111 Reporting Process ........................................................... 7-83
7.5.1 Overview of the Testing Process ................................................................ 7-83
7.5.2 General Testing Requirements................................................................... 7-84
7.5.3 MSP Input File Testing ............................................................................... 7-85
7.5.4 Non-MSP Input File Testing ....................................................................... 7-86
7.5.5 Query Only File Testing .............................................................................. 7-86
7.6 Summary of Steps to Register, Test and Submit Production Files ........................ 7-87
Chapter 8 : Electronic Data Exchange................................................................... 8-1
8.1 File Transmission Methods ...................................................................................... 8-1
8.1.1 Connect:Direct (NDM via the CMSNet) ........................................................ 8-1
8.1.2 Secure File Transfer Protocol (SFTP) .......................................................... 8-2
8.1.3 Hypertext Transfer Protocol over Secure Socket Layer (HTTPS) ................ 8-5
Chapter 9 : Querying for Medicare Coverage Information ................................... 9-1
9.1 How to Obtain Medicare Coverage Information ....................................................... 9-1
9.1.1 File Transmission ......................................................................................... 9-1
9.1.2 Beneficiary Lookup on the Section 111 COBSW ......................................... 9-2
Chapter 10 : Data Use Agreement........................................................................ 10-1
Chapter 11 : Section 111 COB Secure Website (COBSW) ................................. 11-1
Chapter 12 : Customer Service and Reporting Assistance ............................... 12-1
12.1 EDI Representative ................................................................................................ 12-1
12.2 Contact Protocol for the Section 111 Data Exchange ............................................ 12-1
Chapter 13 : Training and Education ................................................................... 13-1
Appendix A MSP File Specifications .................................................................. A-1
Section 111 GHP MSP Input File ..................................................................................... A-1
Section 111 GHP MSP TIN Reference File ................................................................... A-11
Section 111 GHP MSP Response File........................................................................... A-19
Section 111 GHP TIN Reference Response File ........................................................... A-33
Appendix B Query Only HEW File Specifications ............................................. B-1

iii
GHP User Guide Chapter 2: Introduction

Appendix C Non-MSP File Specifications .......................................................... C-1

Section 111 GHP Non-MSP Input File – Expanded Reporting Option Only .................... C-1
Section 111 GHP Non-MSP Response File ..................................................................... C-8
Appendix D Disposition, Error, and Compliance Codes .................................. D-1
Appendix E MMSEA Section 111 Statutory Language ..................................... E-1
Appendix F MMSEA Section 111 Definitions and Reporting ResponsibilitiesF-1
Appendix G Reporting Employer Size................................................................G-1
Appendix H Unsolicited MSP Response File Specifications ........................... H-1
Appendix I Alerts ................................................................................................. I-1
Appendix J Acronyms ........................................................................................ J-1
Appendix K Previous Version Changes ............................................................. K-1

List of Tables
Table 6-1: MMSEA Section 111 Basic GHP Reporting Option Files ...................................... 6-2
Table 6-2: MMSEA Section 111 Expanded GHP Reporting Option Files ............................... 6-3
Table 7-1: Formatting Standards ............................................................................................ 7-5
Table 7-2: Quarterly MSP Input File Submission Timeframes .............................................. 7-15
Table 7-3: Quarterly Update Event Table ............................................................................. 7-33
Table 7-4: Threshold Errors .................................................................................................. 7-47
Table 7-5: Severe Errors ....................................................................................................... 7-48
Table 7-6: Hierarchy Requirements ...................................................................................... 7-53
Table 7-7: Hierarchy Requirements Examples ..................................................................... 7-54
Table 7-8: Modifier Type Code and Modifier Name .............................................................. 7-61
Table 7-9: Change Reason Description ................................................................................ 7-62
Table 7-10: Threshold Errors ................................................................................................ 7-77
Table 7-11: Severe Errors ..................................................................................................... 7-78
Table 7-12: RDS Reason Codes Returned on Unsolicited Response File Record............... 7-83
Table 8-1: SFTP Software Configuration ................................................................................ 8-3
Table 11-1: System-Generated Emails ................................................................................. 11-3
Table A-1: Section 111 GHP MSP Input File Header – 425 bytes ......................................... A-1
Table A-2: Section 111 GHP MSP Input File Detail Record - 425 bytes................................ A-2
Table A-3: Section 111 GHP MSP Input File Trailer Record - 425 bytes............................. A-10
Table A-4: Section 111 GHP MSP TIN Reference Input File Header Record - 425 bytes... A-11
Table A-5: Section 111 GHP MSP TIN Reference Input File Detail Record - 425 bytes ..... A-12
Table A-6: Section 111 GHP MSP TIN Reference Input File Trailer Record - 425 bytes .... A-18
Table A-7: Section 111 GHP MSP Response File Header Record - 800 bytes ................... A-19
Table A-8: Section 111 GHP MSP Response File Detail Record - 800 bytes ..................... A-20
Table A-9: Section 111 GHP MSP Response File Trailer Record - 800 bytes .................... A-32
Table A-10: Section 111 GHP MSP TIN Reference Response File Header Record -
650 bytes ............................................................................................................................. A-33
Table A-11: Section 111 GHP MSP TIN Reference Response File Detail Record -
650 bytes ............................................................................................................................. A-34
Table A-12: Section 111 GHP MSP TIN Reference File Trailer Record - 800 bytes ........... A-38
Table B-1: Section 111 HEW V4.0.0 Query Only Input File Header Record - 200 bytes....... B-1
Table B-2: Section 111 HEW V4.0.0 Query Only Input File Detail Record - 200 bytes ......... B-2
Table B-3: Section 111 HEW V4.0.0 Query Only Input File Trailer Record - 200 bytes ........ B-3

iv
GHP User Guide Chapter 2: Introduction

Table B-4: Section 111 HEW V4.0.0 Query Only Response File Record - 300 bytes ........... B-4
Table C-1: Section 111 GHP Non-MSP Input File Header Record - 300 bytes ..................... C-1
Table C-2: Section 111 GHP Non-MSP Input File Detail Record - 300 bytes ....................... C-2
Table C-3: Section 111 GHP Non-MSP Input File Trailer Record - 300 bytes....................... C-7
Table C-4: Section 111 GHP Non-MSP Response File Header Record - 500 bytes ............. C-8
Table C-5: Section 111 GHP Non-MSP Response File Detail Record - 500 bytes ............... C-9
Table C-6: Section 111 GHP Non-MSP Response File Trailer Record - 500 bytes ............ C-18
Table D-1: Section 111 GHP Disposition Codes ................................................................... D-1
Table D-2: Section 111 GHP SP Error Codes ....................................................................... D-3
Table D-3: Section 111 GHP Rx Error Codes ...................................................................... D-15
Table D-4: SEE Response Codes ....................................................................................... D-16
Table D-5: GHP TIN Reference Response File Record Errors ............................................ D-17
Table H-1: Section 111 GHP Unsolicited MSP Response File Header Record - 600 bytes .. H-1
Table H-2: Section 111 GHP Unsolicited MSP Response File Detail Record - 600 bytes..... H-2
Table H-3: Section 111 GHP Unsolicited MSP Response File Trailer Record - 600 bytes.... H-6
Table J-1: Acronyms ............................................................................................................... J-1

List of Figures
Figure 7-1: MSP Occurrence Add, Update, and Delete Permissions ................................... 7-55
Figure 7-2: MSP Occurrence Update & Delete Permissions ................................................ 7-56
Figure 7-3: Non-MSP File Structure ...................................................................................... 7-70
Figure 7-4: Non-MSP File Structure for RDS Retiree Files ................................................... 7-81

v
GHP User Guide Chapter 1: Summary of Version 5.9 Updates

Chapter 1: Summary of Version 5.9 Updates

The following updates have been made in Version 5.9 of the MMSEA Section 111 GHP User
Guide:
Starting April 5, 2021, the following changes will become effective:
• To improve point-of-sale/pharmacy processing and plan payments, the criteria for several
fields will be changed for users submitting primary and supplemental drug records,
specifically for the Rx Insured ID Number, Rx Group Number, Rx PCN, and Rx BIN
Number on the MSP and non-MSP Input Detail Records (MSP fields 24, 25, 26, 27; Non-
MSP fields 13, 14, 15, 16) (See Sections MSP Input File Detail Record and Non-MSP
Input File Detail Record for more details regarding these updates).
• For MSP and Non-MSP Input File Detail records submitted for a Medicare beneficiary:
• If the coverage dates fall completely outside the Medicare entitlement period or the
record was submitted prior to the effective date of the individual’s Medicare
entitlement, the record will be rejected and returned with a Disposition Code ‘51’
(record could not be matched to a Medicare beneficiary) instead of an SP31 error
code.
• If coverage was terminated prior to the effective date of the individual’s Medicare
entitlement, the record will be rejected and returned with a Disposition Code ‘51’
instead of an SP32 error code. (Appendix D).

1-1
GHP User Guide Chapter 2: Introduction

Chapter 2: Introduction

This guide provides information and instructions for the Medicare Secondary Payer (MSP)
Group Health Plan (GHP) reporting requirements mandated by Section 111 of the Medicare,
Medicaid and SCHIP Extension Act of 2007 (MMSEA) (P.L. 110-173). An overview of Section
111 related legislation, MSP rules, and the GHP reporting process is followed by detailed
instructions and process requirements. Complete explanations of entities that are required to
report and how this reporting will be implemented are included in this guide. File specifications
are located in appendices to this guide for easy reference.
This guide also provides information and instruction for mandatory reporting requirements for
Medicare beneficiaries who have prescription drug coverage under GHP arrangements. Section
4002 of the Substance Use-Disorder Prevention that Promotes Opioid Recovery and Treatment
(SUPPORT) for Patients and Communities Act (“the SUPPORT Act”) mandates the reporting of
primary prescription drug coverage information, in addition to the existing Section 111 reporting
requirements. All GHPs that offer primary prescription drug coverage are required to report this
coverage for calendar quarters beginning on or after January 1, 2020.
This guide is for use by all Section 111 GHP Responsible Reporting Entities (RREs).
Please note that CMS is implementing the Section 111 requirements in phases. As time passes
and we gain experience with Section 111 reporting, the data exchange requirements will continue
to be refined and new processes added when necessary. CMS will issue revised versions of the
Section 111 GHP User Guide from time to time. Please check the CMS Section 111 Mandatory
Insurer Reporting for Group Health Plans Web pages often at https://go.cms.gov/mirghp for the
latest version of the user guide and for other important information. The GHP User Guide can be
found at the following link: GHP User Guide.
CMS provides the ability for you to be automatically notified when changes are made to the
GHP Web pages. If you have not already signed up for these notifications, please click the
Subscription Sign-up for Mandatory Insurer Reporting (GHP) Web Page Update Notification
link found in the Related Links section of the web page and add your email address to the
distribution list. When new information regarding mandatory insurer reporting for GHPs is
available, you will be notified. These announcements will also be posted to the GHP What’s
New page. Additional information related to Section 111 can be found on the login page of the
Section 111 Coordination of Benefits Secure Website (COBSW) at
https://www.cob.cms.hhs.gov/Section111/.
Note: Frequently, CMS will publish new information in the form of an alert which is then
incorporated in subsequent versions of the user guide. Information in published Section 111
alerts supersedes information published in the user guide. To obtain the most up to date
information and requirements related to Section 111 reporting, be sure to review not only the
user guide but any pertinent alerts published subsequent to the current version of the user guide.

2-1
GHP User Guide Chapter 2: Introduction

The Section 111 Resource Mailbox, at [email protected], is a vehicle

that RREs may use to send CMS policy-related questions regarding the MSP reporting
requirements included in Section 111 of the Medicare, Medicaid, and SCHIP Extension Act of
2007. RREs are requested to send only policy-related questions to the Section 111 Resource
Mailbox.
If you have a technical question, or if you are unable to contact your Electronic Data Interchange
(EDI) Representative, for any reason, call the EDI Hotline at (646) 458-6740. If you have not
registered to become an RRE, please contact the Benefits Coordination & Recovery Center
(BCRC) directly at 1-855-798-2627.

2-2
GHP User Guide Chapter 3: MMSEA Section 111 Overview

Chapter 3: MMSEA Section 111 Overview

Section 111 of the Medicare, Medicaid, and SCHIP Extension Act of 2007 (MMSEA Section
111) adds mandatory reporting requirements with respect to Medicare beneficiaries who have
coverage under group health plan (GHP) arrangements as well as for Medicare beneficiaries who
receive settlements, judgments, awards or other payment from liability insurance (including self-
insurance), no-fault insurance, or workers’ compensation. Implementation dates were January 1,
2009, for GHP arrangement information and July 1, 2009, for information concerning liability
insurance, no-fault insurance and workers’ compensation.
The new provisions for GHP arrangements found at 42 U.S.C. 1395y(b)(7):
• Add reporting rules; do not eliminate any existing statutory provisions or regulations.
• Include penalties for noncompliance.
• Contain provisions for the Secretary to share information on Part A entitlement and
enrollment under Part B.
• Include who must report: “an entity serving as an insurer or third-party administrator for
a group health plan…and, in the case of a group health plan that is self-insured and self-
administered, a plan administrator or fiduciary.”
• Include what must be reported: data elements determined by the Secretary.
• Specify that reporting must be done in a form and manner, including frequency, specified
by the Secretary. GHP reporting will be done on a quarterly basis in an electronic format.
Note: You must use the statutory language at 42 U.S.C. 1395y(b)(7) together with the
“Definitions and Reporting Responsibilities” document published in conjunction with the
Paperwork Reduction Act Federal Register Notice for Section 111 to determine if you are a
“responsible reporting entity” for purposes of the Section 111 mandatory GHP reporting
requirements. See Appendix E and Appendix F.

3-1
GHP User Guide Chapter 4: Medicare Entitlement, Eligibility, and Enrollment

Chapter 4: Medicare Entitlement, Eligibility,

and Enrollment

This section provides a general overview of Medicare entitlement, eligibility, and enrollment.
Please refer to https://www.cms.gov for more information on this topic.
Medicare is a health insurance program for:
• people age 65 or older,
• people under age 65 with certain disabilities, and
• people of all ages with End-Stage Renal Disease (permanent kidney failure requiring
dialysis or a kidney transplant).
Medicare has:
Part A Hospital Insurance - Most people receive premium-free Part A because they or a spouse
already paid for it through their payroll taxes while working. Medicare Part A (Hospital
Insurance, or HI) helps cover inpatient care in hospitals and skilled nursing facilities (but not
custodial or long-term care). It also helps cover hospice care and some home health care.
Beneficiaries must meet certain conditions to get these benefits.
Part B Medical Insurance - Most people pay a monthly premium for Part B. Medicare Part B
(Supplemental Medical Insurance, or SMI) helps cover doctors' services and outpatient care. It
also covers some other medical services that Part A doesn't cover, such as some of the services
of physical and occupational therapists, and some home health care.
Part C Medicare Advantage Plan Coverage - Medicare Advantage Plans are health plan
options (like HMOs and PPOs) approved by Medicare and run by private companies. These
plans are part of the Medicare Program and are sometimes called “Part C” or “MA plans.” These
plans are an alternative to the fee-for-service Part A and Part B coverage and often provide extra
coverage for services such as vision or dental care.
Part D Prescription Drug Coverage - Starting January 1, 2006, Medicare prescription drug
coverage became available to everyone with Medicare. Private companies provide the coverage.
Beneficiaries choose the drug plan they wish to enroll in, and most will pay a monthly premium.
Exclusions - Throughout, Medicare has various coverage and payment rules which determine
whether or not a particular item or service will be covered and reimbursed.
Section 111 states that CMS will share Medicare Part A entitlement and Part B enrollment
information with GHP responsible reporting entities (RREs). As of July 2019, CMS will share
Part D enrollment information with RREs who report primary prescription drug coverage. In
your response files you will get information about beneficiary eligibility and enrollment.
The distinction between an individual’s benefit eligibility and benefit enrollment can be
confusing. While it sometimes appears that the two terms are used interchangeably, for CMS
they have very different and distinct meanings.

4-1
GHP User Guide Chapter 4: Medicare Entitlement, Eligibility, and Enrollment

Once an individual is a Medicare beneficiary, he or she is then eligible to participate in

Medicare’s benefit programs, including Part D. Usually, the Medicare beneficiary can choose to
participate, and if he or she does, the first day the beneficiary’s participation is effective is the
date of enrollment in the benefit program. For example, individuals who have aged into
Medicare Part A are then eligible to enroll in Medicare Parts B and D, if they so choose. Once an
application for enrollment is accepted, the beneficiary’s effective date of enrollment is
established.
In summary, an eligible Medicare beneficiary may participate in Medicare program benefits
beginning on his or her date of enrollment in the benefit program. For beneficiaries who choose
to participate in the Part B and D programs, the date of enrollment is, usually, the first day of the
following month.

4-2
GHP User Guide Chapter 5: MSP Overview for GHP

Chapter 5: MSP Overview for GHP

Note: The following paragraphs provide only a very high-level overview of the MSP provisions.
Employers, insurers, third party administrators, group health plans, and other group health plan
sponsors are always responsible for understanding when they are providing coverage primary to
Medicare, and for paying appropriately. See 42 U.S.C. 1395y(b), and 42 C.F.R. Part 411, for the
applicable statutory and regulatory provisions, and CMS manuals and Web pages for further
detail. There are also computer-based training (CBT) modules available for Section 111 RREs
that cover basic MSP topics. See Chapter 13 to learn how to enroll in these courses free of
charge.
Some people who have Medicare also have group health coverage. Often, employer-provided
group health coverage must pay before Medicare does. In that case, Medicare is the secondary
payer. Until 1980, the Medicare program was the primary payer in all cases except those
involving workers’ compensation (including black lung benefits) or veterans’ benefits. Since
1980, new laws have made Medicare the secondary payer for several additional categories of
people. The additional categories of people for whom Medicare is the secondary payer are
described below.
Medicare Secondary Payer
Medicare secondary payer (MSP) is the term used by Medicare when Medicare is not responsible
for paying first.
The terms “Medicare supplement” and “Medicare secondary payer” are sometimes confused. A
Medicare supplement (Medigap) policy is a private health insurance policy designed specifically
to fill in some of the “gaps” in Medicare’s coverage when Medicare is the primary payer.
Medicare supplement policies typically pay for expenses that Medicare does not pay because of
deductible or coinsurance amounts or other limits under the Medicare program. Private
"Medigap" insurance and Medicare secondary payer law and regulations are not the same.
Federal Medicare law takes precedence over conflicting State law and private contracts. Thus,
for the categories of people described below, Medicare is secondary payer regardless of state law
or plan provisions.
Who does MSP affect?
Medicare is now secondary payer to some group health plans (GHPs) or large group health plans
(LGHPs) for services provided to the following groups of Medicare beneficiaries:
• The “working aged,”
• People with permanent kidney failure, and
• Certain disabled people.
Working Aged
The “working aged” are employed people age 65 or over and people age 65 or over with
employed spouses of any age who have GHP coverage because of their or their spouse’s current
employment status. In general, an individual has current employment status if the individual is an
employee, the employer, or is associated with an employer in a business relationship.

5-1
GHP User Guide Chapter 5: MSP Overview for GHP

Medicare is secondary payer to GHPs for the “working aged” where either:
• a single employer of 20 or more full and/or part-time employees is the sponsor of the
GHP or contributor to the GHP,
or
• two or more employers are sponsors or contributors to a multi-employer/multiple
employer plan, and a least one of them has 20 or more full and/or part-time employees.
When determining the “20 or more threshold,” employers (i.e., individual or wholly owned
entities) with more than one company must follow the IRS aggregation rules. The relevant IRS
codes can be found in 26 U.S.C. sections 52(a), 52(b), 414 (n) (2).
There is one exception to the employer size rule for beneficiaries entitled due to age: A multi-
employer/multiple employer GHP may request to exempt specific working aged people enrolled
through an employer with fewer than 20 full and/or part-time employees. If CMS approves the
request, Medicare would become primary payer for specifically identified working aged people
enrolled through a specifically identified employer with fewer than 20 full or part-time
employees. The GHP must be able to document its request and/or CMS approval of its request to
exempt such individuals. See the Small Employer Exception Section 7.2.4 of this guide for more
information.
People with Permanent Kidney Failure
Medicare is the secondary payer to GHPs during a 30-month coordination period for
beneficiaries who have permanent kidney failure (End Stage Renal Disease or ESRD), and who
have coverage under a GHP on any basis (current employment status is not required as the basis
for coverage). The coordination of benefits period applies regardless of the number of full and/or
part-time individuals employed by an employer and regardless of whether or not the employer
belongs to a multi-employer/multiple employer GHP.
Disabled People
Medicare is the secondary payer for people under age 65 who have Medicare because of
disability and who are covered under a Large Group Health Plan (LGHP) based on the
individual’s (or a family member’s) current employment status. In general, an individual has
current employment status if the individual is an employee, the employer, or is associated with
an employer in a business relationship. A LGHP provides health benefits to employees, former
employees, the employer, business associates of the employer, or their families, where the
employer has 100 or more full and/or part-time employees. Where an employer of any size is
part of a multi-employer/multiple employer GHP, Medicare is secondary for individuals who
have Medicare because of a disability if one or more of the employers in the GHP has 100 or
more full and/or part-time employees.
Making MSP Work
The entities under contract to pay Medicare claims ("Medicare contractors") are responsible for
denying claims for primary benefits when Medicare is secondary payer. In making claims
processing decisions, the Medicare contractors use information on the claim form and in CMS
data systems in order to avoid making primary payments in error. Where CMS’ systems indicate
an MSP occurrence, Medicare will deny payment. In such cases, Medicare will not pay the claim
as a primary payer and will return it to the claimant with instructions to bill the proper party.
Sometimes, after a Medicare claim is paid, CMS receives new information that indicates
Medicare made a primary payment by mistake. Based on this new information, CMS takes action

5-2
GHP User Guide Chapter 5: MSP Overview for GHP

to recover the mistaken Medicare payment. CMS uses its Commercial Repayment Center (CRC)
which is responsible for all of the functions and workloads related to GHP MSP recovery with
the exception of provider, physician, or other supplier recovery activities or actions. The CRC
issues a demand letter for repayment to any or all the parties obligated to repay Medicare (the
employer, insurer, third party administrator, plan, or other plan sponsor.) If the CRC does not
receive repayment or a valid documented defense in response, it will refer the debt to the
Department of the Treasury for the Treasury Offset Program and other cross-servicing activities
pursuant to the Debt Collection Improvement Act of 1996. CMS may also refer debts to the
Department of Justice for legal action if it determines that the required payment or a
properly documented defense has not been provided. The law authorizes the Federal
government to collect double damages from any party that is responsible for resolving the
matter, but which fails to do so.
Role of the Medicare Benefits Coordination & Recovery Center
The purposes of the Coordination of Benefits (COB) program are to identify the health benefits
available to a Medicare beneficiary and to coordinate the payment process to prevent mistaken
payment of Medicare benefits. The CMS Benefits Coordination & Recovery Center (BCRC)
consolidates the activities that support the collection, management, and reporting of other
insurance coverage for Medicare beneficiaries. The BCRC does not process claims, nor does it
handle any mistaken payment recoveries or claims-specific inquiries. Instead, the BCRC updates
the Medicare systems and databases used in the claims payment and recovery processes. The
BCRC has been directed by CMS to implement the MSP requirements of the MMSEA Section
111 legislation as part of its responsibilities to collect information in order for CMS to coordinate
benefits for Medicare beneficiaries.
Where to Find MSP Regulations
The sections of the Social Security Act known as the Medicare Secondary Payer (MSP)
provisions were originally enacted in the early 1980s and have been amended several times,
including by the MMSEA Section 111 mandatory reporting requirements. See section 1862(b) of
the Social Security Act (42 U.S.C. 1395y(b). See 42 CFR Part 411 for the applicable regulations.
Medicare has been secondary to workers’ compensation benefits from the inception of the
Medicare program in 1965.
Additionally, the SUPPORT Act, which was signed into law on October 24, 2018, requires
mandatory reporting of primary prescription drug coverage through the Section 111 process. See
also H.R. 6, Public Law No: 115-271 for details regarding the SUPPORT Act.

5-3
Section 111 GHP User Guide Chapter 6: The GHP Reporting Process

Chapter 6: The GHP Reporting Process

6.1 Overview
The purpose of the Section 111 GHP reporting process is to enable CMS to correctly pay for the
health insurance benefits of Medicare beneficiaries by determining primary versus secondary
payer responsibility. Section 111 authorizes CMS and Section 111 GHP responsible reporting
entities (RREs) to electronically exchange health insurance benefit entitlement information. The
actual data exchange process takes place between the RREs and the CMS Benefits Coordination
& Recovery Center (the BCRC). The BCRC manages the technical aspects of the Section 111
data exchange process for all Section 111 RREs.
On a quarterly basis, a responsible reporting entity must submit group health plan (GHP)
entitlement information about employees and dependents to the BCRC. In exchange, the BCRC
will provide the RRE with Medicare entitlement information for those individuals in a GHP that
can be identified as Medicare beneficiaries. This mutual data exchange helps to assure that
claims will be paid by the appropriate organization at first billing. RREs also have the option of
submitting primary prescription drug coverage information, which will become required for
quarters after January 1, 2020.
The Section 111 GHP reporting process includes an option to exchange supplemental
prescription drug coverage information to coordinate benefits related to Medicare Part D. CMS
also allows RREs that are also participating in the Retiree Drug Subsidy (RDS) program or are
reporting to RDS on behalf of a plan sponsor to use the Section 111 GHP reporting process to
submit subsidy enrollment (retiree) files to the RDS Center.
Section 111 RREs are required to register with the BCRC and fully test the GHP data reporting
exchange before submitting production files. You will be assigned a production file submission
timeframe during which you are to submit your files on a quarterly basis. Once you are in a
production mode, you will submit your initial file containing GHP coverage information for all
individuals meeting the definition of an Active Covered Individual, or Active Covered
Individuals identified as Medicare beneficiaries through the query process. Subsequent quarterly
file submissions are to contain only new or changed coverage information using add, delete and
update transactions. These requirements are explained in later sections of this user guide.
The data exchanged through the Section 111 GHP reporting process is arranged in multiple files
with different record layouts. A responsible reporting entity (RRE) electronically transmits a data
file to the BCRC. The BCRC processes the data in this input file by first editing the incoming
data. Other insurance information for Medicare beneficiaries derived from the input file is posted
on the Medicare Common Working File (CWF) and the Medicare Beneficiary Database (MBD)
by the BCRC for use by other Medicare contractors for claims processing and recovery efforts.
When this processing is completed or the prescribed time for response file generation has
elapsed, the BCRC electronically transmits a response file back to the responsible reporting
entity. The response file will include information on any errors found, disposition codes that
indicate the results of processing, and Medicare entitlement/enrollment information as prescribed
by the particular file format.
In ordinary circumstances it will always be an input file that will generate a response file.

6-1
Section 111 GHP User Guide Chapter 6: The GHP Reporting Process

6.2 GHP Reporting Options

Pursuant to Section 111, the Secretary of Health and Human Services (HHS) has determined that
GHP RREs are to provide CMS with information regarding hospital and medical GHP coverage
they make available to Medicare beneficiaries. As required by the SUPPORT Act, GHPs are
required to submit primary prescription drug coverage information using the Section 111
reporting process beginning for calendar quarters on or after January 1, 2020. Section 111 also
provides for CMS to share information regarding a beneficiary's Medicare Part A (hospital)
entitlement, Part B (medical), and Part C (Medicare Advantage) coverage in return. There are
two reporting options available—Basic and Expanded—in the Section 111 GHP reporting
process.
The Basic Reporting Option reflects the minimum requirements you must adhere to in order to
comply with Section 111. The Basic Reporting Option allows you to submit hospital and medical
coverage as well as primary prescription drug coverage information. RREs that offer primary
prescription drug coverage is be required to report this coverage for calendar quarters on or after
January 1, 2020.
The Expanded Reporting Option includes the minimum requirements for Section 111 plus the
exchange of secondary or supplemental prescription drug coverage information. You will then
receive response files with entitlement and enrollment information for Medicare Parts A, B, C,
and D.
The following sections explain each option in further detail. Complete explanations of the file
types listed follow in later sections of this guide.

6.2.1 Basic Reporting Option

The Basic Reporting Option represents the minimum requirements you must adhere to for
compliance with the Section 111 requirements. The Basic Reporting Option includes submission
of the Medicare Secondary Payer (MSP) Input File for hospital and medical coverage of Active
Covered Individuals and, optionally, the Query-Only Input File, in the form of an ANSI X12
270/271 Entitlement Query file, along with the corresponding response files. In response, the
BCRC will return Medicare Parts A, B, C, and D eligibility information and Parts A, B, and C
enrollment information. In addition to your hospital and medical reporting, you can also submit
primary prescription drug coverage. If you do submit primary prescription drug coverage
information, you will also receive Medicare Part D enrollment information. Please note:
reporting of primary prescription drug coverage is required for calendar quarters after January 1,
2020 under the SUPPORT Act.

Table 6-1: MMSEA Section 111 Basic GHP Reporting Option Files
File Type Description
GHP MSP Input File This is the data set transmitted from a MMSEA Section 111 responsible
reporting entity (RRE) to the BCRC that is used to report information
regarding Active Covered Individuals whose GHP coverage may be
primary to Medicare.
GHP MSP Response File This is the data set transmitted from the BCRC to the MMSEA Section 111
RRE after the information supplied in the RRE’s MSP Input File has been
processed.

6-2
Section 111 GHP User Guide Chapter 6: The GHP Reporting Process

File Type Description

TIN Reference File The TIN Reference File consists of a listing of each business entity’s
Federal tax identification number (TIN) and the business mailing address
that is linked to that particular TIN.
TIN Reference Response File This is the data set transmitted from the BCRC to the RRE after the
information supplied in the RRE’s TIN Reference File has been processed.
Query-Only Input File This is a query file used to obtain Medicare Part A entitlement and Parts B
and C enrollment information of potential Medicare beneficiaries.
Query-Only Response File After the BCRC has processed the Query-Only Input File it will return the
Query-Only Response File with Medicare Parts A, B and C coverage
information for individuals identified as Medicare beneficiaries.

6.2.2 Expanded Reporting Option

The Expanded Reporting Option is similar to the former insurer VDSA/VDEA process. It
includes submission of the MSP Input File for primary medical, hospital and prescription drug
coverage for Active Covered Individuals, the Non-MSP Input File with supplemental
prescription drug coverage records, optional Retiree Drug Subsidy (RDS) reporting and
entitlement/enrollment query capability, and the optional Query Only Input File, in the form of
an ANSI X12 270/271 Entitlement Query transaction set. The BCRC will provide response files
with entitlement/enrollment information for Medicare Parts A, B, C, and D with this option.
The Expanded Reporting Option represents the minimum you must adhere to for compliance to
the Section 111 requirements plus the exchange of supplemental or secondary prescription drug
coverage information. If you choose the Expanded Reporting Option, you must provide
supplemental drug coverage records or RDS retiree file records on the Non-MSP Input File.
If you maintain a Coordination of Benefits Agreement (COBA) with CMS for the purposes of
receiving claims paid by Medicare for secondary payment by your plan, then you may submit
supplemental prescription drug information using the COBA Drug Coverage Eligibility (E02)
records and remain compliant with the requirements of the Section 111 Expanded Reporting
Option. Note that we ask for this information during the Section 111 registration process. The
BCRC will track your COBA submissions accordingly.

Table 6-2: MMSEA Section 111 Expanded GHP Reporting Option Files
File Type Description
GHP MSP Input File This is the data set transmitted from a MMSEA Section 111
responsible reporting entity (RRE) to the BCRC that is used to report
information regarding Active Covered Individuals whose GHP
coverage may be primary to Medicare.
GHP MSP Response File This is the data set transmitted from the BCRC to the MMSEA
Section 111 RRE after the information supplied in the RRE’s MSP
Input File has been processed.
TIN Reference File The TIN Reference File consists of a listing of each business entity’s
Federal tax identification number (TIN) and the business mailing
address that is linked to that particular TIN.
TIN Reference Response File This is the data set transmitted from the BCRC to the RRE after the
information supplied in the RRE’s TIN Reference File has been
processed.

6-3
Section 111 GHP User Guide Chapter 6: The GHP Reporting Process

File Type Description

GHP Non-MSP Input File This is the data set transmitted from a MMSEA Section 111 RRE to
the BCRC that is used to report information regarding the drug
insurance coverage information of Inactive (e.g. not employed,
retired) Covered Individuals.
GHP Non-MSP Response File This is the data set transmitted from the BCRC to the MMSEA
Section 111 RRE after the information supplied in the Non-MSP
Input File has been processed.
Query-Only Input File This is a query file used to obtain Medicare Part A entitlement and
Parts B and C enrollment information of potential Medicare
beneficiaries.
Query-Only Response File After the BCRC has processed the Query Only Input File it will
return the Query-Only Response File with Medicare Parts A, B and
C coverage information for individuals identified as Medicare
beneficiaries.

6-4
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Chapter 7: GHP Mandatory Reporting Requirements

7.1 General Reporting Requirements

7.1.1 Responsible Reporting Entities

7.1.1.1 Who Must Report

A GHP organization that must report under Section 111 is defined as “an entity serving as an
insurer or third party administrator for a group health plan…and, in the case of a group health
plan that is self-insured and self-administered, a plan administrator or fiduciary.” These
organizations are referred to as Section 111 GHP responsible reporting entities, or RREs. Note:
You must use the definitions given in Appendix F when determining whether or not you are a
responsible reporting entity under this provision.
The SUPPORT Act mandates the reporting of primary prescription drug coverage by GHP
RREs. The entity considered to be the RRE for the purpose of reporting primary prescription
drug coverage will depend upon how the employer or other plan sponsor facilitates its
prescription drug coverage benefit. The RRE for the primary prescription drug coverage
reporting is the entity that has the direct relationship with the employer or other plan sponsor
regarding the provision of this benefit.
The group health plan arrangements of multi-national organizations, foreign nations, American
Indians and Alaskan Native Tribes that may cover Medicare beneficiaries are subject to the MSP
provisions and must be reported accordingly.

7.1.1.2 Use of Agents

Note: See the discussion of “agents” with respect to GHP reporting in Appendix F.
GHP RREs may use agents to submit data on their behalf. An agent is a data services company,
consulting company, or the like that can create and submit Section 111 files to the BCRC on
behalf of the RRE. Information on the use of agents is required as part of the Section 111
registration process. The RRE remains solely responsible and accountable for adhering to the
requirements of the Section 111 program and for the accuracy of data submitted.

7.1.2 Active Covered Individuals

Section 111 GHP RREs are required to report information for Medicare beneficiaries, who have
GHP coverage which is primary to Medicare and Medicare is the secondary payer, on the MSP
Input File. Since an RRE may not know whether a covered individual is a Medicare beneficiary,
CMS is providing two approaches for RREs to determine whom to report for Section 111. The
first involves reporting on individuals defined as “Active Covered Individuals.” The second
involves using a “finder file” to query on an individual’s Medicare entitlement and enrollment to
determine whether an individual should be included in the MSP Input File. The finder file
method is described in Section 7.1.2.1.

7-1
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Note: Under no circumstances should these two reporting options be construed as requiring
RREs to report on individuals who are not Medicare beneficiaries. Instead these two options,
properly executed, allow RREs to identify and report on all individuals who have Medicare and
for whom Medicare is the secondary payer of benefits, as required by the Section 111 legislation.
The definition of an Active Covered Individual is set forth below. Active Covered Individuals
are to be reported on the RRE’s Section 111 MSP Input File. In many cases, the GHP coverage
being reported will be primary to Medicare. When an RRE uses this reporting method, the
BCRC will determine whether the Active Covered Individual is a Medicare beneficiary based
upon the information submitted and whether the GHP coverage reported is primary to Medicare.
The results of that determination are provided back to the RRE on the MSP Response File. The
phrase “current employment status” in the definition below refers to the subscriber’s
employment status. This includes employees who may be in a temporary disability status. It does
NOT include a subscriber who is a retiree covered by an employer’s retirement plan. Note that
the part of the definition related to individuals with ESRD does not depend on the current
employment status of the subscriber. However, except in certain circumstances where the retiree
has ESRD, individuals covered by a retiree plan would never be considered Active Covered
Individuals and should NOT be reported to CMS as Active Covered Individuals on the MSP File.
Please refer to the MSP Overview for GHP section of this guide (Chapter 5) for further
information on MSP rules.
For purposes of reporting, an Active Covered Individual is defined as someone who may be
Medicare eligible and currently is employed, or the spouse or other family member of a worker
who is covered by the employed individual’s GHP and who may be eligible for Medicare and for
whom Medicare would be a secondary payer for these individuals. On the MSP Input File, CMS
is requiring an RRE using the Active Covered Individual definition to report for Section 111 to
include all of the individuals covered by the GHP for whom, if they had Medicare, Medicare
would be a secondary payer of their GHP benefits. The BCRC will determine if the Active
Covered Individual is a Medicare beneficiary based upon the information submitted and whether
the GHP coverage overlaps Medicare coverage. The results of this determination are then
provided to the submitter on the returned MSP Response File.
For purposes of Section 111 reporting, Active Covered Individuals are further defined to include:
• All individuals covered in a GHP age 45 through 64 who have coverage based on their
own or a family member’s current employment status.
• All individuals covered in a GHP age 65 and older who have coverage based upon their
own or a spouse’s current employment status.
• All individuals covered in a GHP who have been receiving kidney dialysis or who have
received a kidney transplant, regardless of their own or a family member’s current
employment status and regardless of their age.
• All individuals covered in a GHP who are under age 45, 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. When reporting individuals under age 45 in the MSP Input File,
you must submit their Medicare ID, which can be the Health Insurance Claim
Number (HICN) or Medicare Beneficiary Identifier (MBI).
Note: The Medicare ID is also known as the Medicare Number to CMS’ Medicare beneficiaries.

7-2
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

With one exception, coverage through COBRA is not considered GHP coverage. Therefore, an
individual covered by a COBRA plan is not considered an Active Covered Individual and should
not be reported on the MSP Input File. The exception involves active dialysis treatment or
kidney transplant. If the COBRA covered individual is receiving dialysis or has had a kidney
transplant, the individual is considered an Active Covered Individual for reporting purposes.
Additional Notes on Active Covered Individuals:
• If an employer has less than 20 full and/or part-time employees as defined in 42 C.F.R.
Part 411.101 and 42 C.F.R. Part 411.170, and the employer is not part of a multi-
employer/multiple employer GHP, then the covered individuals under that plan do not
have to be reported under Section 111 unless a covered individual is receiving dialysis or
has had a kidney transplant (ESRD).
• The fact that an employer has less than 20 full and/or part-time employees is NOT a basis
for excluding such employees from the Section 111 GHP reporting process if the
employer is part of a multi-employer/multiple employer GHP. Please also refer to the
section of this user guide discussing the Small Employer Exception (Section 7.2.4) and
Appendix G.
• The size of the employer is not relevant with respect to reporting for individuals who
have been receiving kidney dialysis or have received a kidney transplant (ESRD).
• The MSP provisions for the disabled apply to all employers in a multi-employer/multiple
employer GHP if one or more of the employers has 100 or more full and/or part-time
employees as defined in 42 C.F.R. Part 411.101 and 42 C.F.R. Part 411.170.
• See Appendix G for more information on the calculation of employer size and how that
affects MSP and reporting of Active Covered Individuals.
• In regard to reporting individuals under the age threshold who are “known to be entitled
to Medicare,” CMS expects that the RRE “knows” that an individual is entitled to
Medicare when they have a Medicare ID (HICN or MBI) on record or the RRE is paying
primary or secondary to Medicare for a covered individual that has GHP coverage due to
the subscriber’s current employment status. In this case, the RRE “knows” that the
individual is entitled to Medicare and should submit a record for this person with the
Medicare ID on the MSP Input File. This means that the RRE should check their internal
enrollment, “other insurance” or coordination of benefits files or claims payment records
for these circumstances. However, it does not imply that the RRE should send an MSP
Input record or query record for every covered individual under the age threshold to
determine Medicare entitlement if the RRE has no reason to believe these individuals are
entitled to Medicare.
Examples of Active Covered Individuals:
• A subscriber, age 55, is an employee of a company that has had more than 19 employees
for the last several years. The subscriber’s spouse, age 46, is also covered by the plan. In
this case, both the subscriber and his or her spouse are Active Covered Individuals due to
age. Coverage information should be submitted on the MSP Input file for each on
separate reporting records.
• A subscriber, age 44, is an employee of a company that has had more than 19 employees
for the last several years. The subscriber’s spouse, age 56, and his or her son, age 10, are
also covered by the plan. In this case, only the spouse qualifies as an Active Covered

7-3
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Individual since the spouse is over the age threshold. Only the spouse’s GHP coverage
information should be submitted on the MSP Input File.
• A subscriber, age 44, is an employee of a company with any number of employees. The
subscriber’s son, age 10, is also covered by the plan. The son is known to have ESRD and
be entitled to Medicare. In this case, the son is an Active Covered Individual, but the
subscriber is not. GHP coverage information for the son should be submitted on the MSP
Input File. Since the son is under 45, his Medicare ID (HICN or MBI) must be
included.
• A subscriber is a retiree and the subscriber and his or her spouse are covered by the GHP
through the subscriber’s retirement plan. Neither is known to have ESRD. Neither is
considered an Active Covered Individual since the subscriber is not currently employed.
No information should be sent on these individuals on the MSP Input File.
• A subscriber is an employee of a company that has had more than 19 employees for the
last several years and the subscriber and his or her spouse are both 67. The subscriber’s
spouse is not covered by the GHP. Only the subscriber is an Active Covered Individual
since his or her spouse is not covered by the plan. Only information on the subscriber will
be sent on the MSP Input File.
• A subscriber, age 66, is an employee of a company that has had less than 20 employees
for the last several years. The subscriber is not known to have ESRD and not known to be
a Medicare beneficiary. The employer is NOT part of a multi-employer GHP. Even
though the subscriber fits the definition of an Active Covered Individual, since the
employer has less than 20 employees and is not part of a multi-employer GHP, this
individual does not have to be reported on the MSP Input File. Alternatively, a record for
the subscriber could be submitted but the BCRC will determine that the coverage is not
primary to Medicare due to the employer’s size.

7.1.2.1 Finder File Approach to Determining Whom to Report

A second approach that can be used to determine which individuals to report is the “finder file.”
This approach involves the RRE first sending a query file of Active Covered Individuals through
which the BCRC would identify any Medicare beneficiaries based on the information submitted
and return these positive identifications to the RRE. The RRE would then submit MSP Input File
records for those identified Medicare beneficiaries who have coverage based on their own or a
family member’s current employment status or those known to have ESRD and for whom
Medicare should be the secondary payer of benefits.
If you choose to use the “finder file” approach, query records must be submitted via the Query
Only Input File (Basic or Expanded Reporting Option) or as N records on your Non-MSP Input
File (Expanded Reporting Option only). Requirements for these file submissions are provided in
a later section of this guide. Note that a Non-MSP Input File cannot be submitted with only N
records. The query file must be submitted in a timely fashion such that you are able to meet the
requirements for quarterly file submission of your MSP Input File during your assigned file
submission timeframe. Query records must be submitted using accurate information for the data
elements the BCRC uses as matching criteria for individuals (Medicare ID [HICN or MBI] or
Social Security Number [SSN], name, date of birth, and gender). Query files will only be
accepted once per calendar quarter. See Section 7.3 for more information on the query process.
All other requirements for the MSP Input File must be adhered to including reporting applicable
individuals with new or changed coverage with each quarterly submission.

7-4
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

7.1.3 Inactive Covered Individuals

Inactive Covered Individuals are to be reported on your Non-MSP Input File and can be
submitted on your Query Only Input Files. In most cases for these individuals, the GHP coverage
you provide will be secondary to Medicare and Medicare will be the primary payer.
Inactive Covered Individuals are people who are currently not employed (most are carried as
retired), and a spouse and (or) other dependents, enrolled in your GHP who cannot be classified
as Active Covered Individuals. Do NOT submit Inactive Covered Individuals on your MSP
Input File.

7.1.4 File Format

All data files submitted for Section 111 must be fixed width, flat files. All records in the file
must be the same length as specified in the file layouts. All data fields on the files are of a
specified length and should be filled with the proper characters to match those lengths. No field
delimiters, such as commas between fields, are to be used. Detailed record and field
specifications are found in the appendices of this guide.
Header, Detail and Trailer Records
Each input file format contains at least three record types. The file begins with a header record.
Header records identify the type of file being submitted and will contain your Section 111 RRE
ID. You will receive your RRE ID on your profile report after your registration for Section 111 is
processed. Detail records represent coverage information or query requests for individual people.
Each file always ends with a trailer record that marks the end of the file and contains summary
information including counts of the detail records for validation purposes. Each header record
must have a corresponding trailer record. Each trailer record must contain the proper count of
detail records. Do not include the header and trailer records in these counts. If the trailer
record contains invalid counts, your file will be rejected.

7.1.5 Data Formatting Standards

Conventions for Describing Data Values
The following table defines the formatting standard for each data type found in the Section 111
files, both input and response. These standards apply unless otherwise noted in specific file
layouts.

Table 7-1: Formatting Standards

Data/Field Type Formatting Standard Examples
Numeric Zero through 9 (0 - 9) Numeric (5): “12345”
Padded with leading zeroes Numeric (5): “00045”
Alpha A through Z Alpha (12): “TEST EXAMPLE”
Left justified Alpha (12): “EXAMPLE “
Non-populated bytes padded with
spaces
Alphabetic characters sent in lower
case will be converted and returned in
upper case.

7-5
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Data/Field Type Formatting Standard Examples

Alphanumeric A through Z (all alpha) Alphanum (8): “AB55823D”
0 through 9 (all numeric) Alphanum (8): “MM221 “
Left justified
Non-populated bytes padded with
spaces
Alphabetic characters sent in lower
case will be converted and returned in
upper case.
Text A through Z (all alpha) + 0 through 9 Text (8): “AB55823D”
(all numeric) + special characters: Text (8): “XX299Y “
Comma (,) Text (18):
Ampersand (&) “[email protected]”
Space ( ) Text (12): “ 800-555-1234”
Dash (-) Text (12): “#34 “
Period (.)
Single quote (‘)
Colon (:)
Semicolon (;)
Number (#)
Forward slash (/)
At sign (@)
Left justified
Non-populated bytes padded with
spaces
Alphabetic characters sent in lower
case will be converted and returned in
upper case.
Date/Numeric Date All dates are in the format of century, “20110419”
year, month and day supplied as Open ended date: “00000000”
CCYYMMDD.
Default input value is all zeroes for
open-ended dates, such as a
termination date that has not yet been
established or determined.
Date fields on response files may be
returned with a valid date or default
values of all zeroes or all spaces if not
applicable.
Filler Populate with spaces n/a
Internal Use Populate with spaces n/a

7-6
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

7.1.6 Section 111 Registration

7.1.6.1 Overview
The registration process requires responsible reporting entities (RREs) to provide notification to
the BCRC of their intent to report data to comply with the requirements of Section 111 of the
MMSEA. Registration by the responsible reporting entity is required and must be completed
before testing between the RRE (or its agent) and the BCRC can begin. Through the registration
process, the BCRC will obtain the information needed to:
• Validate information provided by the RRE registrant.
• Assign Section 111 Reporter IDs or Responsible Reporting Entity Identification Numbers
(RRE IDs) to each RRE.
• Develop a Section 111 reporting profile for each entity including estimates of the volume
and type of data to be exchanged for planning purposes.
• Assign a production live date and ongoing file submission timeframe for MSP Input Files
to each entity.
• Establish the necessary file transfer mechanisms.
• Assign an Electronic Data Interchange (EDI) Representative to each entity to assist with
ongoing communication and data exchange.
• Assign Login IDs to individual users associated with each RRE ID account.
New Section 111 GHP RREs will register on the Section 111 COB Secure Website (COBSW)
using an interactive Web portal designed for this purpose. The registration process will remain
available in the future for new RREs to register and for existing RREs that need to change their
reporting structure.
The Section 111 COBSW website URL is https://www.cob.cms.hhs.gov/Section111/.
Once you click on the “I Accept” link and accept the terms of the Login Warning, the homepage
will display. Information on the New Registration and Account Setup processes can be found
under the “How To” menu option. A Login ID is not needed to access this menu option. Click
on the menu option and a drop-down list will appear. Then click on the item desired in the list. In
particular, please read the documents found under “How to Get Started” and “How to Invite
Account Designees.” Once you have begun the registration process on the Section 111 COBSW,
you will have access to “Help” information on each page displayed. By clicking on the link for
the Help page, a new window will open with instructions and information needed to complete the
page you are working on. Once you have finished the New Registration and Account Setup steps
and obtain a Login ID for the Section 111 COBSW, you may log into the application using the
Login fields displayed on the right side of the homepage. After login, a detailed Section 111
COBSW User Guide is available under the “Reference Materials” menu option. You must be
logged into the application to gain access to the user guide.
Note: Entities who are RREs for purposes of the Section 111 GHP reporting are not required to
register if they will have nothing to report. For example, a TPA that administers and pays claims
only for certain stand-alone or “carve-out” GHP coverage that does not overlap Medicare
coverage (dental, behavioral health, etc.), may not have anything to report. However, if a TPA is
contracted directly with the plan sponsor to provide prescription drug coverage, the TPA is
considered the RRE and will have to register. RREs who do not register initially because they
currently have no expectation of having GHP coverage to report, must register in time to allow a

7-7
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

full quarter for testing if they have future situations where they have a reasonable expectation of
having to report.

7.1.6.2 Registration and Account Setup Process

Section 111 registration and account setup is a five-step process.
Step 1: Identify an Authorized Representative, Account Manager and other COBSW Users
Each RRE must assign or name an Authorized Representative. This is the individual in the RRE
organization who has the legal authority to bind the organization to a contract and the terms of
MMSEA Section 111 requirements and processing. This is normally a person at the executive
level of the organization. The Authorized Representative has ultimate accountability for the
RRE’s compliance with Section 111 reporting requirements. Please refer to the Data Use
Agreement in Chapter 10 and make sure the person you name as your Authorized Representative
has the authority to sign this agreement.
The Authorized Representative:
• Cannot be a user of the Section 111 COBSW for any RRE ID.
• Cannot be an agent of the RRE.
• May perform the initial registration on the COBSW, but will not be provided with a
Login ID.
• Will designate the Account Manager.
• Must approve the account setup, by physically signing the profile report, which includes
the Data Use Agreement, and returning it to the BCRC.
• Will be the recipient of BCRC notifications related to non-compliance with Section 111
reporting requirements.
Each RRE must assign or name an Account Manager. Each RRE ID can have only one Account
Manager. This is the individual who controls the administration of an RRE’s account and
manages the overall reporting process. The Account Manager may choose to manage the entire
account and data file exchange, or may invite other company employees or data processing
agents to assist.
The Account Manager:
• Must register on the COBSW, obtain a Login ID and complete the account setup tasks.
• Can be an Account Manager associated with another RRE ID if they receive the
authorized PIN from the BCRC mailing. This can occur when a reporting entity has
multiple RRE IDs under which they will report separate MSP Input Files or when the
entity chooses to name an agent as its Account Manager.
• Can invite other users to register on the COBSW and function as Account Designees.
• Can manage the RRE’s profile including selection of a file transfer method.
• Can upload and download files to the COBSW if the RRE has specified HTTPS as the
file transfer method.
• Can use his or her Login ID and Password to transmit files if the RRE has specified SFTP
as the file transfer method.
• Can review file transmission history.
• Can review file-processing status and file statistics.

7-8
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

• Can remove an Account Designee’s association to an RRE ID account.

• Can change account contact information (e.g., address, phone, etc.)
• Can change his or her personal information.
• Cannot be an Authorized Representative for any RRE ID or an Account Designee for the
same RRE ID.
At the RRE’s discretion, the Account Manager may designate other individuals, known as
Account Designees, to register as users of the COBSW associated with the RRE’s account.
Account Designees assist the Account Manager with the reporting process. Account Designees
may be RRE employees or agents.
The Account Designee:
• Must register on the COBSW and obtain a Login ID.
• Can be associated with multiple RRE accounts, but only by an Account Manager
invitation for each RRE ID.
• Can upload and download files to the COBSW if the RRE has specified HTTPS as the
file transfer method.
• Can use his or her Login ID and Password to transmit files if the RRE has specified SFTP
as the file transfer method.
• Can review file transmission history.
• Can review file-processing statuses and file statistics.
• Can change his or her personal information.
• Cannot be an Authorized Representative for any RRE ID or the Account Manager for the
same RRE ID.
• Cannot invite other users to the account.
• Cannot update RRE account information.
Note: Each user of the Section 111 application on the COBSW will have only one Login ID and
password. With that Login ID and password, you may be associated with multiple RRE IDs
(RRE accounts). With one Login ID, you may be an Account Manager for one RRE ID and an
Account Designee for another. In other words, the role you play on the COBSW is by RRE ID.
Step 2: Determine Reporting Structure
Before beginning the registration process, an RRE must also determine how the RRE will submit
its Section 111 files to the BCRC and how many Section 111 Reporter IDs (RRE IDs) will be
needed. Only one MSP Input File may be submitted on a quarterly basis for each RRE ID. Due
to corporate organization, GHP enrollment system structures, data processing systems, data
centers and agents that may be used for file submission, you may want to submit more than one
MSP Input File to the BCRC on a quarterly basis and therefore need more than one RRE ID in
order to do so.
For example, if an RRE will use one agent to submit one set of GHP coverage information and
another agent to submit another set of GHP coverage information, the RRE must register on the
COBSW twice to obtain two RRE IDs that will be used by each agent respectively. You may
name the same Authorized Representative and Account Manager for both accounts, or use
different individuals. Likewise, if you have two or more subsidiary companies that handle GHPs
for different regions of the country (or different lines of business) using different

7-9
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

enrollment/claims systems and you will not combine the MSP Input Files for Section 111
reporting, you must register for each claim file submission to obtain separate RRE IDs in order
to submit multiple MSP Input Files in one quarter.
You may not set up a separate RRE ID for submission of the Query Only File or Non-MSP Input
File only. You must submit MSP Input Files for every RRE ID you establish.
You must complete the New Registration and Account Setup steps on the Section 111 COBSW
for each RRE ID you want, so careful consideration must be given to the number of RRE IDs
you request. Once logged into the Section 111 COBSW, most functions are performed by each
RRE ID. Your Account Manager must invite and identify Account Designees that will need
access to multiple accounts by RRE ID. File transmission and viewing the results of file
processing is done by RRE ID. So, to ease the management of reporting, account maintenance
and user access, we suggest that fewer RRE IDs are better than many. The registration process
will remain available indefinitely. You may request one or more additional RRE IDs in the future
if changes in your business operations require changes in your data reporting requirements. If
you register and obtain an RRE ID that you later determine you will not need, contact your EDI
Representative to have it disabled.
You are not required to obtain an RRE ID for each subsidiary separately, but you must do so if
separate input files will be submitted for each or if each/any subsidiary is handling its own
reporting. Alternatively, the parent organization may register, obtain one RRE ID and report for
all applicable subsidiaries under that RRE ID.
Claims processing TPAs are often the RRE. Please refer to the definitions of an RRE in other
sections of this guide. A GHP TPA RRE is not required to register and obtain separate RRE IDs
for each client’s GHP data. If you process all of your clients’ GHP data in one system and can
submit one combined file, you need only one RRE ID for the GHP TPA. One MSP Input File
can be submitted per quarter. The individual GHPs will be defined using the Employer/Plan
Sponsor TINs submitted on the GHP TPA’s MSP Input File.
If you register for multiple RRE IDs:
• You can use the same TIN for each or different TINs for each. No matching is done
between the TINs supplied at registration and the TINs supplied on your input files.
• You can name the same Authorized Representative for each or a different Authorized
Representative for each.
• You can name the same Account Manager for each or a different Account Manager for
each.
The system randomly assigns EDI Representatives to RRE IDs. If you register for multiple RRE
IDs and want them all assigned to one EDI Representative, then contact one of the assigned EDI
Representatives and request a reassignment of all RRE IDs to one EDI Representative.
Step 3: RRE Registration on the COBSW – New Registration
A company representative for the RRE must go to the Section 111 COBSW URL
(https://www.cob.cms.hhs.gov/Section111/), click on the “New Registration” button, complete
and submit the registration for the RRE. This step must be completed by the RRE, not an agent
for the RRE. It must be performed for each RRE ID needed for Section 111 reporting.

7-10
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

The application will ask that you submit:

• A Federal Tax Identification Number (TIN) for the RRE
• Company name and address
• Company Authorized Representative contact information (name, job title, address, email
address, phone)
• National Association of Insurance Commissioners (NAIC) company code, if applicable
• Reporter Type (Select GHP)
• Optional Subsidiary company information to be included in the file submission for the
registration (names, TINs, NAIC company codes for the subsidiaries)
• If your organization does not have NAIC company codes, you may default these fields to
zeroes
It is critical that you provide contact information for your Authorized Representative in this step
regardless of who is actually performing this task on the Section 111 COBSW. The Authorized
Representative cannot be a user of the Section 111 COBSW for any RRE ID. If you need to
change your Authorized Representative after completing this step, you must contact your
assigned EDI Representative.
When a registration application is submitted, the information provided will be validated by the
BCRC. Once this is completed, the BCRC will send a letter via the US Postal Service to the
named Authorized Representative with a personal identification number (PIN) and the BCRC-
assigned RRE ID (Section 111 Reporter ID) associated with the registration. Your Authorized
Representative should receive the PIN letter within 10 business days after the New Registration
step is completed.
The Authorized Representative must give this PIN and RRE ID to their Account Manager to use
to complete the Account Setup step on the Section 111 COBSW.
Each time this step is completed, a new RRE ID is generated by the system. If you need more
than one RRE ID for Section 111 reporting, this step must be repeated for each. If you
erroneously completed this step for more RRE IDs than needed, please contact the EDI
Department to have the RRE IDs that you will not be using deleted.
Note: Information for subsidiaries is optional. CMS encourages you to supply this information.
Doing so will assist us in our efforts to help ensure that you are in compliance with the Section
111 reporting requirements. Further, we may require this information at a later date during
subsequent recovery efforts. However, all TINs supplied for subsidiaries under one RRE ID must
be unique. In other words, all TINs for the RRE ID and subsidiaries listed in the New
Registration step must be different within one specific RRE ID. If your subsidiaries do not have
different TINs, then do not list them on the corporate structure page of the New Registration step
on the COBSW. You can use the same TIN for multiple, different RRE IDs. TINs just need to be
unique within the same RRE ID. For example, if you are one entity with one TIN registering five
different RRE IDs, you can use the same TIN for all five distinct RRE IDs. The subsidiary
information on the corporate structure page is not required. If you have trouble with data entry
on this page, you may simply click the Continue button to bypass it.
Step 4: RRE Account Setup on the COBSW – Account Manager
In order to perform the RRE Account Setup tasks, the RRE’s Account Manager must go to the
Section 111 COBSW website (https://www.cob.cms.hhs.gov/Section111/) with the PIN and RRE
ID and click the “Account Setup” button.
7-11
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

The Account Manager will:

• Enter the RRE ID and associated PIN.
• Enter personal information including name, job title, address, phone and email address.
• Create a Login ID for the COBSW.
• Enter account information related to expected volume of data to be exchanged under this
RRE ID (estimated number of covered individuals and estimated number of covered
individuals age 45 and over).
• Enter reporting agent name, address, contact email and TIN if applicable.
• Select a file transmission method.
• Provide dataset naming information needed if the Connect:Direct transmission method is
selected. Refer to Section 8.1.1 for more information. You must have destination
dataset names available if the Connect:Direct method is selected or this step cannot
be completed and all the other data you provided will be lost.
Once the Account Manager has successfully obtained a COBSW Login ID, he or she may log
into the application and invite Account Designees to register for Login IDs. In addition, after
completing Account Setup for his or her first RRE ID, since only one Login ID is required per
user, the Account Manager will bypass the steps for creating another Login ID and password
when setting up subsequent RRE IDs.
The Account Setup step must be completed by your Account Manager. In this step, the Account
Manager will obtain a Login ID and must personally agree to the terms of the User Agreement. If
you need to change your Account Manager after completing this step, contact your assigned EDI
Representative.
This step must be repeated for each RRE ID.
Step 5: Return Signed RRE Profile Report – Authorized Representative
Once Account Setup has been completed on the COBSW (including file transmission details for
Connect:Direct if that method is selected) and processed by the BCRC, a profile report will be
sent to the RRE’s Authorized Representative and Account Manager via email. You should
receive your profile report within 10 business days after completing the Account Setup step on
the COBSW.
The profile report contains:
• A summary of the information you provided during New Registration and Account
Setup.
• Important information you will need for your data file transmission.
• Your RRE ID that you will need to include on all files transmitted to the BCRC.
• Your assigned production live date and ongoing quarterly file submission timeframe for
the MSP Input File.
• Contact information for your EDI Representative who will support you through testing,
implementation and subsequent production reporting.
The RRE’s Authorized Representative must review, sign and return the profile report to
the BCRC. Once your profile report has been marked as received by the BCRC, you may begin
testing your Section 111 files. The BCRC will send an email to your Authorized Representative
and Account Manager indicating that testing can begin.

7-12
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

The status of your RRE ID will be updated by the system as each step of the registration process
is completed. Once the BCRC receives your signed profile report, your RRE ID will be placed in
a “testing” status. Once testing is completed (See Section 7.5), your RRE ID will be placed in a
“production” status. RRE IDs are expected to move to a production status within 180 days after
initiation of the registration process (completion of the New Registration step).
Profile reports are regenerated and emailed to the RRE’s Authorized Representative and Account
Manager on an annual basis, based on the receipt date of the last signed profile report. The
RRE’s Authorized Representative must review, sign and return the profile report to the BCRC
within 30 days of receipt to confirm or update account information and active reporting status for
the RRE ID. Failure to return the signed profile report may result in deactivation of the RRE ID.

7.1.6.3 Changes to RRE Registration and Reporting

This section provides information regarding steps RREs must take if changes occur after initial
Section 111 registration is completed.

Abandoned RRE IDs

If you erroneously registered for an RRE ID that you no longer need or have abandoned due to
starting the registration process over, and you will not use the RRE ID for Section 111 file
submission, please contact your assigned EDI Representative to have that RRE ID deleted.
Unused RRE IDs may trigger automated warning notifications and follow-up by the BCRC to
the associated Authorized Representative and/or Account Manager. Delete requests should only
be made for RRE IDs that have never been used for production file submission.

Ceasing and Transitioning Reporting

If you have been reporting production Section 111 files under an RRE ID but will cease
reporting under it in the future due to changes in your reporting structure, changes to what entity
is the RRE, ceasing business operations or other reasons, then please contact your assigned EDI
Representative. Inform your EDI Representative of circumstances affecting the change. Since the
RRE ID was used for production reporting, it will not be deleted. You and your EDI
Representative will create a transition plan and your EDI Representative will change the status of
your RRE ID to an “inactive” status after your last production file has been processed. Once the
status is changed, information for the RRE ID will remain in the BCRC Section 111 system.
However, production file submissions will no longer be accepted or expected. This change in
RRE ID status will prevent the automatic generation of the Late File Submission emails and
subsequent follow-up contact by the BCRC to your Authorized Representative and Account
Manager related to Section 111 reporting compliance.
The transition of reporting responsibility from one RRE to another is the responsibility of the
RREs involved. The BCRC cannot supply a file of previously submitted and accepted records for
use in the transition by the new or former RRE or their reporting agents. For example, if a GHP
transitions to a new claims-processing TPA, it is likely that the new TPA will become the RRE
for Section 111 reporting. The new TPA may register for a new RRE ID or report the GHP
coverage under one of its existing RRE IDs. The new TPA RRE may update and delete records
previously submitted by the former TPA RRE under a different RRE ID as long as the key fields
for the MSP occurrences match. The RRE IDs do not need to match. The former RRE must
NOT delete previously submitted and accepted records. If the coverage previously reported has
ended, then update transactions should be sent with applicable Termination Dates. The new RRE
may send add transactions for new coverage information or update transactions to change

7-13
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

existing records with new information such as the new Insurer/TPA TIN. Please see Section
7.2.6.1 for more information on submitting add and update transactions.
If an RRE is changing reporting agents, the new agent should continue to submit files under the
RRE’s existing RRE ID(s). Again, the BCRC cannot supply a file of previously submitted and
accepted records for the RRE IDs. It is the RRE’s responsibility to coordinate the transition of
reporting from the former agent to the new agent. Individuals from the new reporting agent
should be given access to the RRE ID on the Section 111 COBSW. This can be done by the
Account Manager for the RRE ID by using the Designee Maintenance action off the RRE Listing
page and inviting these individuals as Account Designees. The new agent may then use their
COBSW login ID for access to the RRE ID on the COBSW as well as for the HTTPS and SFTP
file transmission methods. The Account Manager should remove any Account Designees
associated with the former agent from their RRE ID account on the COBSW.
If you have questions regarding your specific circumstances related to ceasing or transitioning
reporting, please contact your EDI Representative.

Changing RRE Information

After registration is completed on the Section 111 COBSW, your Account Manager may update
certain information related to the RRE profile. After logging on to the COBSW
(https://www.cob.cms.hhs.gov/Section111/), Account Managers may use the RRE Information
action off the RRE Listing page to update the RRE name, address and telephone information.
Changes to other information such as reporting agent, file transmission method or TIN associated
with the RRE ID must be requested through your EDI Representative. You must also contact
your EDI Representative to change your Authorized Representative or Account Manager to a
different individual.
Note that all users of the COBSW may update their own personal information associated with
their login ID, such as email address or phone number, after logging on to the site.

7.1.7 File Submission Timeframes

An RRE is to submit the MSP Input File on a quarterly basis during its assigned file submission
timeframe. You will receive your file submission timeframe assignment on your profile report
which is sent after the BCRC has processed your Section 111 registration. It also is displayed on
the RRE Listing page after logging on to the Section 111 COBSW. Each 3-month calendar
quarter of the year has been divided into 12 submission periods as shown in the chart below. For
example, if you have been assigned to Group 7, you will submit your MSP Input and associated
TIN Reference File between the 15th and 21st day of the second month of each calendar year
quarter; February 15th and February 21st for the first quarter, May 15th and May 21st for the
second quarter, August 15th and August 21st for the third quarter and November 15th and
November 21st for the fourth quarter of each year.
Note: Your MSP Input File receipt date will be set by the BCRC system when the batch cycle
runs. The BCRC batch cycle runs nightly Monday-Friday, except holidays. RREs must send their
files as close to the first day of their submission timeframe as possible in order to have the file
receipt date fall within their submission timeframe. For example, if you submit a file on a
Saturday, the BCRC system will not mark the receipt date until the BCRC batch cycle runs on
Monday night. In addition, if the batch cycle runs past midnight, your file receipt date might not
be set until Tuesday. The seven-day submission window is provided to account for this delay
between file transmission and receipt date determination. It is not intended to allow you more

7-14
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

time to submit your file. You should be ready to transmit your files to the BCRC on the first day
of your submission timeframe to be compliant with Section 111 reporting requirements
(Table 7-2).
TIN Reference Files may be sent as often as needed at any time during a calendar quarter. Many
RREs choose to submit a TIN Reference File with every MSP Input File submission. Since
information from the TIN Reference File is needed for successful processing of the MSP Input
File, your TIN Reference File must be submitted and successfully processed before or at the
same time as your MSP Input File.
There is no submission timeframe associated with Query Only or Non-MSP Input Files. You
may start sending the Query Only Input File on a quarterly basis and the Non-MSP Input File as
frequently as monthly, after your production live date, on any day of the month.

Table 7-2: Quarterly MSP Input File Submission Timeframes

Dates 1st Month 2nd Month 3rd Month
01 - 07 Group 1 Group 5 Group 9
08 - 14 Group 2 Group 6 Group 10
15 - 21 Group 3 Group 7 Group 11
22 - 28 Group 4 Group 8 Group 12

7.2 MSP Input File Requirements

7.2.1 Overview
The MSP Input File is the data set transmitted from a Section 111 GHP responsible reporting
entity to CMS that is used to report information regarding Active Covered Individuals who are
Medicare beneficiaries. Please review Sections 7.1.2 and 7.1.2.1 for information on the reporting
using the definition of Active Covered Individuals and the finder file approach. If using the
definition of Active Covered Individuals to report, you must include information about all Active
Covered Individuals who are at least 45 years of age and older. You must also include
information on Active Covered Individuals you know or should know to be Medicare
beneficiaries and those being treated for End Stage Renal Disease (ESRD). Some of the
individuals on this file will obviously not be Medicare beneficiaries but CMS has determined
that by using this age threshold, information for the majority of Medicare beneficiaries will be
captured. Note that the age threshold was lowered to 45 from 55 effective January 1, 2011. If you
are using the finder file method, you must report on all Active Covered Individuals identified as
Medicare beneficiaries through the query process.
CMS uses the information in the MSP Input File to determine GHP coverage for Medicare
beneficiaries that is primary to Medicare, data which is then used for proper claims payment. If
your hospital/medical coverage for a Medicare beneficiary covered by Parts A and/or B during
the same time period is primary to Medicare, the BCRC sets up what is known as an “MSP
occurrence” on the Medicare Common Working File (CWF). In the case of prescription drug
coverage primary to Medicare for a Medicare beneficiary covered by Part D during the same
time period, the MSP occurrence is established on the Medicare Beneficiary Database (MBD).
MSP occurrences have start and end dates based on the beneficiary’s Medicare entitlement and
enrollment and your coverage dates. An MSP occurrence will have an open-end date if both your
coverage and Medicare coverage are active. An end date is applied when either the GHP or
7-15
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Medicare coverage ends. The BCRC collects other health insurance information for Medicare
beneficiaries from many sources so an MSP occurrence established from your data may get
changed as a result of information received from other sources at times. Hierarchy rules the
BCRC applies when processing data from different sources are described in Section 7.2.8.3.
This file format requires you to initially send an “add” record for the first report of coverage for
an Active Covered Individual. If that record is accepted by CMS as reflecting MSP (coverage
primary to Medicare) then you only need to apply any changes to that information in “update” or
“delete” records going forward. If the record is not accepted due to errors, you must correct it
and resend. If the record is not accepted due the individual not being a Medicare beneficiary,
then you must continue to send current information for the individual as an add record on all
subsequent submissions until the record is either accepted, the individual is no longer an Active
Covered Individual or your GHP coverage is terminated. Alternatively, you may monitor the
Medicare status of the individual using the query process and resend the associated MSP record
when Medicare entitlement is established or re-established.
An MSP Response File will be sent back to you by the BCRC for each MSP Input File you send.
This is the data set transmitted from BCRC to the GHP RRE after the information supplied on
the MSP Input File has been processed. It consists of the same data elements in the Input File,
with updates applied by the BCRC based on Medicare’s information for that individual,
disposition and error codes which let you know what we did with the record, as well as
applicable Medicare entitlement and enrollment information.
MSP Input, TIN Reference, MSP Response and TIN Reference Response Files and data element
specifications can be found in Appendix A.
All Section 111 GHP RREs, regardless of the reporting option chosen, must submit MSP Input
Files on a quarterly basis.
Note: On the MSP Input File, RREs are only to report individuals who have GHP coverage
based on their own or a family member’s current employment status or those known to have
ESRD. It is important that you do not submit information for those covered by a retirement
plan, where Medicare is the primary payer, on this file.

7.2.2 TIN Reference File

CMS uses IRS-assigned Tax Identification Numbers or TINs to identify insurers, TPAs and
employers. The TIN is the same as the Federal Employer ID Number, the FEIN or EIN. The TIN
Reference File is submitted with or prior to the MSP Input File so that Insurer and Employer
name and address information does not have to be repeated on every MSP Input Record. The
mailing address associated with each TIN on the TIN Reference File should be the address
to which health care insurance coordination of benefits issues, claims payment issues and
recovery demands should be directed.
The TIN Reference File may be submitted within your MSP Input File as a logically separated
file within the same physical file, or as a completely separate physical file. It has its own header
and trailer records. It must be sent prior to or at the same time as your first MSP Input File.
The TIN Reference File is to be submitted with a record for each insurer and employer TIN
reported in Fields 21 and 22 of your MSP Input File. This includes all associated insurer TINs
submitted and a record for each employer group or other plan sponsor TIN used. If the RRE is a
TPA, then the TIN Reference File will contain records for all of its TPA TINs used on the MSP
Input File in Field 22 as well as records for each of its client employer groups or other plan

7-16
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

sponsors that are reported in Field 21 of the MSP Input File. Any insurer/TPA or employer TIN
submitted on an MSP Input record must be included in the TIN Reference File in order for the
MSP Input record to process. Every TIN submitted in Field 21 or 22 on the MSP Input File
must have an associated record submitted for it on the TIN Reference File.
The TIN Reference File must contain only one record per unique TIN and TIN Indicator
combination. In most cases, a TIN has only one associated TIN Indicator (Field 8 of the TIN
Reference File). The valid values include ‘I’ for an insurer/TPA TIN, ‘E’ for an employer TIN,
‘S’ for other plan sponsor TIN (e.g., a union or health and welfare fund), ‘F’ for a Federal
Employer TIN, and ‘Z’ for a TIN that reflects a foreign employer without a valid TIN. In the
case of an RRE that is a self-insured employer that administers its own plan, the same TIN may
represent the insurer and employer. In this situation, two TIN Reference File records for the self-
insured/self-administered employer plan TIN should be submitted, one with a TIN Indicator of
‘I’ and the other with a TIN Indicator of ‘E’, ‘S’, or ‘F’ depending on the type of plan sponsor.
Note: Each Insurer/TPA TIN submitted in Field 22 of MSP Input File Detail Records must have
a matching TIN Reference File Detail Record with a TIN Indicator of ‘I’. Each Employer TIN
submitted in Field 21 of MSP Input File Detail Records must have a matching TIN Reference
File Detail Record with a TIN Indicator of ‘E’, ‘S’, ‘F’, or ‘Z’. Failure to submit corresponding
TIN Reference File Records with appropriate TIN Indicators for Insurer/TPA and Employer
TINs will result in errors on MSP Response File records.
A submitted TIN Reference File will generate a corresponding TIN Response File. Errors on
TIN Reference File records will result in the rejection of subsequently processed MSP Input File
Detail Records that have matching TINs. Please refer to Section 7.2.2.2 for more information.
The TIN Reference File layout and field descriptions can be found after the MSP Input File
layout in Appendix A.
Note: You do not need to send a TIN Reference File with every MSP Input File submission.
After the initial TIN Reference File is processed, you only need to resend it if you have changes
or additions to make. Only new or changed TIN records need to be included on subsequent
submissions. However, many RREs choose to submit a full TIN Reference File with each MSP
Input File submission. All TINs will be verified so it is imperative that accurate information be
provided in the file.
Formatting Employer TIN Records
Employer TIN – TIN Indicator ‘E’
Under typical circumstances, TIN Reference File Detail Records submitted for employer
TINs will have an ‘E’ in the TIN Indicator. However, there are several special cases
concerning the reporting of employer TINs described below.
Other Plan Sponsor TIN – TIN Indicator ‘S’
A plan sponsor TIN must be used in place of individual employer TINs in the case of all
multiple employer/multi-employer plans. RREs are not to report the individual employer
TINs in the case of a multiple employer/multi-employer plan, but instead report the overall
plan sponsor TIN (e.g., workers’ union or trade group). The plan sponsor TIN should be
entered in Field 21, Employer TIN, on each applicable MSP Input File Detail Record for
Active Covered Individuals covered by the multiple employer/multi-employer plan. A
corresponding TIN Reference File Detail Record should be submitted with a value of ‘S’ in
the TIN Indicator (Field 8), and the plan sponsor’s TIN, name and address provided in
Fields 1-7.
7-17
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Note: The Commercial Repayment Center (CRC) directs GHP recovery demands to the
entity identified by the Employer TIN (Field 21). Therefore, in the case of a multiple
employer/multi-employer plan, the plan sponsor is responsible for responding to Medicare
for related recovery demands.
Federal Employer TIN – TIN Indicator ‘F’
Employer TIN records submitted on the TIN Reference File that are associated with Federal
employer entities should be submitted with a value of ‘F’ in the TIN Indicator (Field 8).
Note: If the Federal Employer is the Office of Personnel Management, please ensure that the
correct TIN is submitted in Field 21 (Employer TIN) on the MSP Input File Detail Record so
that the correct entity is established as the primary debtor.
Foreign Employer TIN – TIN Indicator ‘Z’
In certain rare circumstances, an RRE may be required to report records which reflect
coverage of an Active Covered Individual provided by a foreign employer that does not have
an IRS-assigned TIN. For example, the RRE may be a healthcare insurer based in the US, the
Active Covered Individual a US citizen entitled to Medicare who works for an employer in
Canada (may or may not reside in the US), and the Canadian employer sponsors healthcare
coverage for the employee through the US-based insurer RRE under which the covered
individual may be covered for healthcare services provided in the US. The Canadian
employer might not have a TIN and might not have an address in the US.
In circumstances like these, the RRE must create a fake or “pseudo-TIN” for the foreign
employer and submit that in Field 21 of the applicable MSP Input File Detail Records. A pseudo-
TIN is a 9-digit number made up by the RRE to represent an employer in lieu of a valid
employer TIN. Pseudo-TINs must be unique within RRE ID. A TIN Reference File Detail
Record must also be submitted for the foreign employer with the pseudo-TIN in Field 1 and a
value of ‘Z’ in the TIN Indicator (Field 8). If the employer does not have an address in the US,
then use the Foreign Employer Address Fields described below.
Foreign Employer Address Fields
To accommodate reporting of foreign employers with no US address, a set of address fields
is provided on the TIN Reference File Detail Record, the Foreign Employer Address Lines 1-
4 (Fields 15-18). Since there are numerous differences in the format of international
addresses, these text fields are 32 bytes each and the RRE may provide the address using
these fields in a “free form” manner of their choosing as long as at least the first address line
Field 15 is supplied. Components of the address (e.g., street, city) should be separated by
spaces.
The Foreign Employer Address Line fields may only be used on TIN Reference File Detail
Records with a TIN Indicator of ‘E’, ‘S’, or ‘Z’. A value of ‘FC’ must be submitted in the
State Code Field 6 of the record to indicate that a foreign address is being supplied in Fields
15-18. When the State Code in Field 6 is equal to ‘FC’, then some non-blank values must be
supplied in Foreign Employer Address Line 1 (Field 15) and spaces must be submitted in
Fields 3, 4, 5 and 7.

7-18
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Formatting Insurer/TPA TIN Records

Insurer/TPA Addresses
Most often only one address is needed for a given Insurer/TPA TIN. However, an RRE can
have more than one TIN. For example, an insurer or TPA may have claims operations
defined for various regions of the country. Because they are separate business operations,
each could have its own TIN, and each TIN may be associated with a distinct business
mailing address. This mailing address will help CMS and others to direct correspondence to
the most appropriate contact for the GHP RRE. If the RRE has more than one TIN, you may
choose to report all records under one primary Insurer/TPA TIN or use different TINs on
different records with different addresses as you see fit.
The Insurer/TPA name and address provided in Fields 2-7 of the TIN Reference File will be
used for contact regarding claims payment, coordination of benefit issues, and to send a
courtesy copy of the recovery demand package to the RRE if applicable. This address is
posted to MSP occurrences on CWF and made available to providers and suppliers who
erroneously submit claims to Medicare as the primary payer instead of secondary.
If the RRE wishes to provide a different address for the recovery demand information, then
Fields 9-14 (Insurer/TPA Demand Mailing Name and Address) may be used. These fields are
optional. If left blank, then CMS will only use Fields 2-7 to contact the RRE. If Fields 9-14
are supplied, then Fields 2-7 will be used to contact the RRE for claim payment and
coordination of benefits issues and Fields 9-14 will be used by the CRC to contact the RRE
regarding recovery demand issues. Fields 2-7 are always required. Fields 9-14 are optional
but may only be supplied on TIN Reference File Detail Records where the TIN Indicator is
‘I’. Fields 9-14 may not be used on employer TIN Reference File Detail Records. Only one
address is allowed per unique employer TIN.
Again, the use of the Insurer/TPA Recovery Demand Mailing Name and Address is optional.
If not used, then leave the fields blank on all TIN Reference File Records.
Changing TINs or TIN Addresses
If an RRE wishes to change the name and/or address associated with an Insurer/TPA or
Employer TIN, then two actions must be taken. First, a new TIN Reference File must be
submitted with the new address supplied on the applicable TIN Reference File Detail Record.
Second, all the MSP Input File Detail Records previously submitted with the associated TIN that
received an “01” disposition code must be resubmitted as update transactions in order to
associate the new address with the TIN on the MSP occurrence. This will insure that the new
address is posted to the MSP occurrence and passed to other Medicare contractors for claims
processing. These updates are to be made with your regular quarterly file submission unless
otherwise instructed by your EDI Representative.
Note: The most recent name and address submitted on a TIN Reference File Detail Record will
always be used for communications related to recovery demand activity, even if the RRE did not
resubmit related MSP Input File Detail Records with the TIN record update.

7.2.2.1 TIN Validation

• An employer/other plan sponsor TIN in Field 21 of the MSP Input File Detail Record
must match a TIN on a current or previously submitted TIN Reference File record. The
TIN Reference File record must have a TIN Indicator of ‘E’, ‘F’, ‘S’, or ‘Z’.

7-19
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

• An insurer/TPA TIN in Field 22 of the MSP Input File Detail Record must match a TIN
on a current or previously submitted TIN Reference File record. The TIN Reference File
record must have a TIN Indicator of ‘I’.
• All employer and insurer/TPA TINs submitted must be valid IRS-assigned tax IDs
(except for foreign employer pseudo-TINs). Only the TIN will be used in this validation.
The name and address do not have to match the name and address associated with the
TIN by the IRS.
• No validation is done on RRE-assigned pseudo-TINs submitted for foreign employers
(TIN Indicator of ‘Z’) other than to check for a 9-digit number.

7.2.2.2 Address Validation and TIN Reference Response File

Basic TIN Reference File Field Validation
• The BCRC will process TIN Reference Files submitted with MSP Input Files first. RREs
may also submit a TIN Reference File without submission of an MSP Input File and the
system will proceed with processing the TIN file in the next scheduled batch cycle. There
is no file submission timeframe associated with a separately submitted TIN Reference
File.
• Basic field validations will be performed according to the field descriptions in the TIN
Reference File layouts in Appendix A.
• Each insurer/TPA and employer TIN will be validated to ensure it is a valid IRS-assigned
tax ID. Only the TIN will be used in this validation. The name and address do not have to
match the name and address associated with the TIN by the IRS.
• If an error is found on an input TIN Reference File Detail Record during the basic field
validation step, the TIN record will be rejected and returned on the TIN Reference
Response File with a ‘TN’ disposition code and error codes specific to the errors, as
identified in Appendix D.
• As with other Section 111 file processing, certain severe errors will be generated and
notification returned to RREs via email alerts for TIN Reference Files. These include
severe errors for missing header or trailer records, incorrectly formatted header and trailer
records, an invalid record count on the trailer, and empty files. In the event of a severe
error, RREs must contact their assigned EDI Representative and resubmit a corrected
TIN Reference File as instructed.
Address Validation
• TIN Reference File records that pass the basic field validation edits will be further
processed by the BCRC using a postal software tool. This tool will be used to validate
and improve the deliverability of mailing addresses.
• Non-foreign addresses will be reformatted into the standardized format as recommended
by the U. S. Postal Service (USPS), so that they can be matched against a database of
valid, deliverable addresses. This will involve changes like correcting misspellings,
changing the order of the individual components of the primary address line, and
applying standard postal abbreviations such as RD for “Road”.
• After the address is standardized, it will be matched to the postal database. This matching
will include Delivery Point Validation (DPV). If an address is matched to one that is
considered an undeliverable address, such as a vacant lot, the address will not be
considered valid.
7-20
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

• When a match to a deliverable address is confirmed, the address is considered a valid

address.
• The general return codes from the postal software will be translated into more descriptive
error codes that will indicate why the address failed to be validated in this step. These
errors include TN18 – TN29 as shown in Appendix D.
• Address validation will be applied to the following addresses on TIN Reference input file
records that have passed all the basic field validations:
• Insurer/TPA Address in TIN Reference File Fields 3 – 7 where the TIN Indicator
equals ‘I’
• Insurer/TPA Demand Address in TIN Reference File Fields 10-14 where the TIN
Indicator equals ‘I’
• Employer Address in TIN Reference File Fields 3 – 7 where the TIN Indicator equals
‘E,’ ‘F,’ ‘S,’ or ‘Z’ and the State code in Field 6 is not equal to ‘FC’
• Foreign Employer Addresses, submitted on TIN records with a TIN Indicator of ‘E,’
‘S,’ or ‘Z’ where the State code in Field 6 equals ‘FC,’ will not be validated in this
step. Only the basic field validations will apply to the Foreign Employer Address.
• If an insurer/TPA TIN Reference File Detail Record (TIN Indicator of ‘I’) has both an
insurer/TPA “claims office” address in Fields 3-7 and an insurer/TPA demand address in
Fields 10-14, both addresses will be matched to the postal database, even if the first fails,
so that all address errors can be identified and returned to the RRE on the corresponding
TIN Reference Response File Detail Record.
TIN Reference Response File
• TIN Reference Response Files will start with a header record, followed by detail records
for each submitted TIN Reference File Detail Record, and end with a trailer record
containing a detail record count. Each record is a fixed length of 650 bytes. The file
layout is shown in Appendix A.
• The TIN Reference Response File Detail Record will contain the submitted TIN, a
disposition (TIN Disp) code, ten error code fields, the submitted insurer/TPA/employer
mailing address, applied mailing address, submitted insurer demand address, applied
insurer demand address, submitted TIN indicator, submitted foreign employer address,
and indicators to show whether the system applied changes to the mailing or insurer
demand address fields.
• If a TIN Reference File Detail Record fails the TIN and/or TIN address validation, it will
be rejected, and a corresponding TIN Reference Response File Detail Record returned
with:
• A value of ‘TN’ in the TIN Disp Code (Field 29)
• Associated errors in the TIN Error Code 1-10 (Fields 30 – 39)
• TIN Reference File name and addresses in the corresponding submitted name and
address fields (Fields 2 – 7, 14 – 19, 25 - 28)
• Spaces in the applied addresses (Fields 8 – 12, 20 – 24)
• TIN Indicator provided in the input record in the Submitted TIN Indicator (Field 13)
• Spaces in the Mailing Address Change Flag (Field 40) and Demand Address Change
Flag (Field 41)

7-21
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

• If a TIN Reference File Detail Record passes the TIN and TIN address validation, it will
be accepted, and a TIN Reference Response File Detail Record returned with:
• A value of ‘01’ in the TIN Disp Code (Field 29)
• Spaces in the TIN Error Code 1-10 (Fields 30 – 39)
• TIN Reference File name and addresses in the corresponding submitted name and
address fields (Fields 2 – 7, 14 – 19, 25 - 28)
• TIN Indicator provided in the input record in the Submitted TIN Indicator (Field 13)
• Addresses the BCRC will use for subsequent processing in the corresponding applied
addresses (Fields 8 – 12, 20 – 24)
• If the applied address for the insurer/TPA or employer (Fields 8 – 12) is different
from the submitted address (Fields 3 – 7), the Mailing Address Change Flag (Field
40) will be set to ‘Y.’ If they are the same, Field 40 will be set to ‘N.’
• If the applied Insurer/TPA Demand Address (Fields 20 – 24) is different from the
Submitted Insurer/TPA and Demand Address (Fields 15 – 19) the Demand Address
Change Flag (Field 41) will be set to ‘Y.’ If they are the same, Field 41 will be set to
‘N.’ If there was a TIN Reference File Detail Record previously submitted that
matches the TIN and TIN Indicator of the new TIN Reference File Detail Record
being processed, the new record will overlay the prior record on the COB database
and the new record will be used for subsequent MSP Input File processing, regardless
of the TIN Disp Code returned. New TIN records in error can replace previously
existing TIN records that were determined to be valid. Note: Errors on TIN Reference
File records will result in rejection of subsequently processed MSP Input File Detail
Records with matching insurer/TPA or employer TINs. TIN records returned with
errors must be corrected and resubmitted in order for the corresponding MSP records
to process correctly.
• TIN Reference Response Files will be created for both test and production TIN Reference
File submissions.
• Email notifications will be sent to the Account Manager for the RRE ID when a response
file has been transmitted or is available for download.
• RREs are encouraged, but not required, to update their internal systems with the applied
address fields returned.
Processing TINs on the MSP Input File
• The Insurer/TPA TIN (MSP Input Field 22) and Employer TIN (MSP Input Field 21) will
be matched to the COB database table of valid, accepted TIN Reference File records
submitted by the RRE.
• If a match is found, the TIN information will be used in creation of MSP occurrences and
subsequent Medicare claims processing and recovery processing at the CRC.
• If a match is not found to a valid TIN record, the MSP Input File Detail Record will be
rejected and returned on the MSP Response File with an ‘SP’ disposition code and an
error code indicating that a valid TIN record could not be found. These errors will be
specific to insurer/TPA TIN (SPT1) and employer TIN (SPT0) but will not provide
information as to why the TIN record was rejected. RREs will have to refer to the
errors returned on their TIN Reference Response Files to determine what caused the
matching TIN record to be rejected. It will be necessary for an RRE to resubmit corrected

7-22
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

TIN Reference File records, along with resubmitting the corresponding MSP Input File
Detail Records that were rejected, in their next file submission or as instructed by their
EDI Representative.
RREs are encouraged to pre-validate employer and insurer/TPA addresses using postal software
or online tools available on the USPS website pages such as
https://tools.usps.com/go/ZipLookupAction!input.action. RREs should use standard
abbreviations and adhere to USPS standards. The address validation enhancements effective in
the BCRC Section 111 system will ‘scrub’ addresses submitted on the TIN Reference File using
USPS standards, but it is recommended that RREs attempt to adhere to these standards as well to
improve results.

7.2.3 Record Matching Criteria

7.2.3.1 Individuals
To determine whether an individual is a Medicare beneficiary, the BCRC must match your data
to Medicare’s. This matching can be done using either an individual’s Medicare ID (HICN or
MBI) or by using an individual’s SSN. The Medicare ID is preferred and once the Medicare ID
is returned on a response file, the RRE is required to use it on all subsequent transactions. To
determine whether an individual is a Medicare beneficiary you must send either a Medicare ID
or an SSN as part of the individual’s record in the MSP Input File or the Query Only Input File.
For matching an individual to determine if they are a Medicare beneficiary the BCRC uses:
Medicare ID or SSN
Note: The Medicare ID is also known as the Medicare Number to CMS’ Medicare beneficiaries.
• First initial of the first name
• First 6 characters of the last name
• Date of birth (DOB)
• Gender (Sex)
First the BCRC must find an exact match on the Medicare ID or SSN. Then at least three out of
the four remaining criteria must be matched exactly. If a match is found, you will always be
returned the beneficiary’s most current Medicare ID (HICN or MBI) to use going forward on all
update and delete transactions. You must store this Medicare ID on your internal files and are
required to use it on future transactions.
Note that MSP Input File Detail Records submitted for individuals under age 45 must include the
Medicare ID for that individual. See the description for error code SP99 in Appendix D. No
matching will be done on an MSP Input File Detail Record, for an individual under age 45, if the
Medicare ID is not submitted. However, Query Input File Detail Records may be submitted with
only the individual’s SSN, regardless of their age, and the system will proceed with the matching
process and return a Medicare ID on the Query Response File Detail Record if a match is found.
Also note that if an RRE submits both the SSN and Medicare ID on an MSP Input File Detail
Record or a query record, the system will only use the Medicare ID for matching purposes and
the SSN will be ignored. The system will attempt to match the Medicare ID to any previously
assigned Medicare ID for the individual, since Medicare IDs can change or be reassigned by the
Social Security Administration, but if no match is found using the Medicare ID it will not then
make a second attempt to match using the SSN provided.

7-23
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

MSP Occurrences
MSP occurrences created and stored by the BCRC for Medicare claims processing are keyed by:
• Medicare ID (HICN or MBI)
• MSP Effective Date
• Insurance Coverage Type (hospital, medical, drug, etc.)
• Patient Relationship Code (self, spouse, dependent, etc.)
• MSP Type (reason coverage is primary – working aged, ESRD, disability, etc.)
The BCRC will use this criteria for subsequent update and delete transactions you send. You
should save the MSP Effective Date returned to you on the response files in your internal files so
it can be used for claims processing.
The Insurance Coverage Type is what you provide on your MSP Input File. The MSP Type is
generated by the BCRC and depends on the reason the beneficiary is entitled to Medicare and
why the GHP coverage is primary. You must send the Medicare ID that the BCRC sends back on
the MSP Response File on all subsequent MSP Input File update and delete transactions.
Note: Since Medicare often determines entitlement/eligibility in advance, MSP Effective Dates
returned may be future dated.

7.2.4 Small Employer Exception (SEE)

If an employer, having fewer than 20 full and/or part-time employees, sponsors or contributes to
a single-employer GHP, the MSP rules applicable to individuals entitled to Medicare on the basis
of age do not apply to such individuals. However, if such an employer participates in a multiple
employer or multi-employer GHP and at least one participating employer has at least 20 full
and/or part-time employees, these MSP rules apply to all individuals entitled to Medicare on the
basis of age, including those associated with the employer having fewer than 20 employees. The
law provides that a multi-employer GHP may be granted an exception with respect to certain
individuals entitled to Medicare on the basis of age and who are covered as a named insured or
spouse (covered individual) of an employer with fewer than 20 full and/or part-time employees.
In order for an MSP SEE to exist, the multi-employer GHP must request, and the CMS BCRC
must approve, the exception to the Working-Aged MSP rules. An approved exception will apply
only with respect to the specifically named and approved beneficiaries associated with a
specifically named employer participant in a specifically identified multi-employer plan. This
exception applies only to individuals entitled to Medicare on the basis of age. All approvals
are prospective. To request Medicare approval of a SEE, the multi-employer GHP must submit a
written request, with all required supporting documents, to the CMS’ BCRC stating that the plan
seeks to elect Medicare as the primary payer for identified beneficiaries who are associated with
identified employers that participate in the specific multi-employer plan.
For the purposes of requesting the SEE, the term multi-employer GHP shall mean any trust, plan,
association or any other arrangement made by one or more employers to contribute, sponsor,
directly provide health benefits, or facilitate directly or indirectly the acquisition of health
insurance by an employer member. (If such facilitation exists, the employer is considered to be a
participant in a multi-employer GHP even if it has separate contract with an insurer.) However,
the GHP can, by agreement or otherwise, delegate the responsibility for requesting the SEE to
the insurer.

7-24
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Multi-Employer GHPs & Medicare Entitlement Based Upon Disability or ESRD:

If an employer participates in a multi-employer GHP and at least one participating employer has
at least 100 full and/or part-time employees, the MSP rules apply to all individuals entitled to
Medicare on the basis of disability, including those associated with the employer having fewer
than 100 full and/or part-time employees.
There are no exclusions to the MSP rules based upon employer size where Medicare entitlement
is based upon ESRD/permanent kidney failure.
GHP RRE Section 111 Reporting with Respect to the SEE:
The multi-employer GHP or insurer must submit the SEE request for each applicable covered
individual and employer to the BCRC. If the BCRC approves the request, the start and end dates
for the SEE are recorded in the BCRC database by covered individual (Medicare ID [HICN or
MBI]) and employer (EIN) along with the associated start and end dates for the SEE.
If reporting on an Active Covered Individual for whom a SEE has been granted, place the
individual’s Medicare ID in MSP Input File Field 32, Small Employer Exception Medicare ID. If
the BCRC can match this to its records, then the insurance effective date from the submitted
MSP Input File record will be compared to the SEE start and end dates.
Note: The BCRC will not check its database for a SEE unless the RRE submits the individual’s
Medicare ID in the SEE Medicare ID field. If that field is not populated, the record will not be
compared to the database of approved SEE periods and instead be treated as though no SEE has
been approved for that individual and employer.
• If the insurance coverage period is entirely within the SEE start and end dates, no
working-aged MSP occurrence will be created, and the coverage will not be considered
primary to Medicare. A disposition code of ‘BY’ (bypassed) and a SEE Response Code
(Field 81) of ‘SA’ (SEE Accepted) will be returned on the MSP Response File.
• If the insurance effective date is prior to the SEE start date, an MSP occurrence will be
generated if the individual was covered by Medicare for that period. The MSP Effective
Date will be set as the insurance effective date submitted on the MSP Input File. The
MSP Termination Date will be 1 calendar day prior to the SEE start date. The appropriate
disposition code for the updated record and a SEE Response Code of ‘SP’ (SEE Partial)
will be returned on the MSP Response File record.
• If the insurance effective date is within the SEE effective period and the insurance end
date is after the close of the SEE effective period, the MSP Effective Date will be set to 1
calendar day after the SEE termination date. The appropriate disposition code for the
updated record and a SEE Response Code of ‘SP’ (SEE Partial) will be returned on the
MSP Response File record.
• If an MSP occurrence is created because the insurance coverage period is outside of the
SEE effective period, the appropriate disposition code for the updated record and a SEE
Response Code of ‘SN’ (SEE Not Applicable) will be returned on the MSP Response File
record.
If a SEE match is not found, an MSP occurrence will be generated if applicable. A SEE
Response of ‘SN’ (SEE Not Applicable) will be returned to the submitter indicating that the SEE
Medicare ID was not found. This will give the submitter the opportunity to advise the multi-
employer plan that CMS has no record of an approved SEE. The plan may then, if it wishes to do
so, request a SEE.

7-25
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

It is the RRE’s responsibility to correct records that result in MSP occurrences that overlap a
SEE effective period. This could happen if the RRE failed to submit the SEE Medicare ID (Field
32) on the MSP Input File Detail Record or if the SEE was approved subsequent to the MSP
Input File submission with a retroactive SEE start date. To correct the record, the RRE must
submit a delete transaction that matches the previously submitted and accepted add transaction
(response returned with an ‘01’ disposition code) followed by an add transaction with the SEE
Medicare ID supplied in Field 32 for reconsideration of MSP by the BCRC.
Please refer to the Small Employer Exception page at
https://www.cms.gov/Medicare/Coordination-of-Benefits-and-
Recovery/EmployerServices/Small-Employer-Exception.html on the CMS website for more
information on applying for a SEE.

7.2.5 Initial MSP Input File Submission

To begin reporting for Section 111, you must create and send a file that contains information for
all Active Covered Individuals (or Active Covered Individuals who are identified to be Medicare
beneficiaries through the query process) and who are currently enrolled in your plan. Information
must be supplied for individuals who had active coverage at that time even if it has since been
terminated. Information must be supplied for individuals even if their coverage has since been
terminated. Information must also be supplied for individuals who are currently enrolled at the
time of the report.
At least one record is to be supplied for each individual who qualifies as an Active Covered
Individual, including the subscriber, the subscriber’s spouse, and every other dependent that fits
the definition of an Active Covered Individual. If an individual had multiple periods of coverage
during this timeframe, multiple records must be submitted with the applicable Effective and
Termination (end) Dates (Fields 10 and 11). The Effective Date should reflect when the coverage
was initially effective even if that occurred prior to your initial plan. If the coverage is current
and open at the time of the report, the record should reflect an open-ended coverage by putting
zeroes in the Termination Date (Field 11). Termination Dates should only be supplied when the
actual coverage reported has ended. (Note: The date submitted in the Coverage Termination
Date (Field 11) should be the last day that the Active Covered Individual is covered through a
GHP due to current employment (with the exception of situations involving ESRD). Please see
Section 7.2.6.1, How to Report a Coverage Termination Date for Active Covered
Individuals, for additional information. Yearly renewals of the same coverage are not to be
reported as separate records. If the coverage remains the same from year to year, a new record
does not need to be reported since the previous report should have had an open-ended
Termination Date.
Your initial MSP Input File will obviously be larger than your subsequent update files since it
will contain the entire population of your Active Covered Individuals for whom you must report.
All records on your initial file will be “add” records and have a value of zero (‘0’) in the
Transaction Type (Field 7).
When you register for Section 111 reporting, you will be assigned a production live date and a 7-
day window for your quarterly file submission. The production live date is the first day of your
first quarterly submission timeframe and your initial MSP Input File must be received inside that
7-day window.
You must submit a TIN Reference File prior to or with your initial MSP Input File submission.

7-26
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

7.2.6 Quarterly Update MSP Input File Submissions

Each subsequent quarter after your initial MSP Input File submission, you must send an update
MSP Input File to reflect any changes from the last submission, including new enrollees
(subscribers and dependents) who are Active Covered Individuals, existing subscribers and
dependents who are now Active Covered Individuals, changes to previously submitted records,
corrections to previously submitted records, and updates to report on a coverage termination
date.
Note that you may not have reported on an individual in your plan(s) previously since they were
not an Active Covered Individual at that time. Each quarter you must check to see if they now fit
that definition (i.e., have reached the age threshold, diagnosed with ESRD, been identified as a
Medicare beneficiary though the query process, etc.) and send them on your quarterly update
file.
If you are reporting any new TINs on your MSP Input File, submit a TIN Reference File with
records for each new TIN with your update MSP Input File submission.
If you have nothing to report for a given quarter, you may either submit an “empty file” with a
header record, no detail records and a trailer record with a zero-record count or submit no file at
all. Empty files are not required. If an empty file is submitted, you will not receive an MSP
Response File.

7.2.6.1 Add, Delete, Update Transactions

Add Transactions
An “add” record or transaction is defined with a ‘0’ (zero) in the Transaction Type (Field 7).
An add is a new record of coverage information that the BCRC has not posted to the
Medicare CWF or MBD as an MSP occurrence. Records accepted and added as an MSP
occurrence to the CWF or MBD receive a ‘01’ disposition code in your MSP Response File
you receive back from the BCRC. An add transaction could be a record never sent before or a
record that was sent before but not accepted due to errors or the individual not being a
Medicare beneficiary during the GHP coverage period at the time of processing.
Example: Mr. John X. Smith has not yet been included on an MSP Input File. Although he
had health insurance as a covered benefit through his employer, Mr. Smith was not yet 45
years of age. Mr. Smith reaches age 45. Consequently, in the next quarterly update MSP
Input File, a record for Mr. Smith is sent as an add transaction if he was still covered under
the plan after age 45. Note that as an alternative, the RRE may submit a query record for Mr.
Smith and determine whether to include him on the MSP Input File based on whether his
information was matched to a Medicare beneficiary or not.
Example: Information about Mr. John Jones, an Active Covered Individual, was included on
a previous MSP Input File as an add transaction, but the record did not include enough of Mr.
Jones’ required personal identification data elements. The BCRC could not determine
whether the name and SSN submitted belonged to a Medicare beneficiary, and so this
attempt to add Mr. Jones was rejected. With the next quarterly update MSP Input File, an add
transaction is sent with complete personal identification data elements for Mr. John Jones.
The record now includes enough information for the BCRC to confirm that he is a
beneficiary and is accepted.
Note: If rejected again, the record must continue to be sent as an add transaction (or re-
queried using the finder file method) until you receive a response file from the BCRC
7-27
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

indicating the individual is a Medicare beneficiary and an MSP occurrence was posted, until
the individual no longer satisfies the definition of an Active Covered Individual, or until the
individual is no longer covered by the plan.
Update Transactions
An “update” record or transaction is defined with a ‘2’ in the Transaction Type
(Field 7). An update transaction is sent when you need to change information on a record
previously accepted and added as an MSP occurrence to the Medicare CWF or MBD by the
BCRC for which you received a ‘01’ disposition code in your MSP Response File. An update
is only to be used if the record was previously accepted with a ‘01’ disposition code. If a
record with coverage that needs to be reported has not yet been accepted with a ‘01’
disposition code, it must be submitted as an add transaction. Please see the information on
disposition codes in Section 7.2.8.
To successfully update a previously added record, the BCRC must be able to match on the
key fields of the MSP occurrence. Please refer to the Record Matching Criteria in Section
7.2.3 of this guide. The BCRC will use this criterion for update and delete transactions you
send. You must save the Medicare ID (HICN or MBI) returned to you on the response files in
your internal file so it can be used in subsequent update and delete transactions. Report the
actual GHP effective date for the individual. The BCRC will make the necessary calculations
to match to the GHP effective date to the effective date of the corresponding MSP
occurrence.
Example: In January, an add transaction was sent for an Active Covered Individual
identified as a Medicare beneficiary, and an MSP occurrence was created and posted for the
individual by the BCRC. Subsequently, the individual stopped working and retired. The
beneficiary’s last day of employment was July 15th. On the next quarterly update MSP Input
File, an update transaction is sent with July 15th in the termination date (i.e., the last day of
current employment). The BCRC updates the MSP occurrence previously posted with this
termination date which will result in an indication that Medicare is the primary payer
subsequent to July 15th. Note that an update record is sent to report the termination date, not
a delete record.
Delete Transactions
A “delete” record or transaction is defined with a ‘1’ in the Transaction Type
(Field 7). A delete transaction is sent to remove an erroneous MSP occurrence previously
posted to the CWF or MBD by the BCRC. Records accepted and added as an MSP
occurrence to the CWF or MBD receive a ‘01’ disposition code in your MSP Response File
you receive back from the BCRC. If your add transaction did not result in a ‘01’ disposition
code, there’s no need to delete it even if it was previously sent in error.
To successfully delete a previously added record, the BCRC must match on the key fields of
the MSP occurrence. Please refer to the Record Matching Criteria section in Section 7.2.3 of
this guide. The BCRC will use this criterion for update and delete transactions you send. You
must save the Medicare ID (HICN or MBI) returned to you on the response files in your
internal system and use it in subsequent update and delete transactions to assure a match.
Aside from the transaction type and possibly the Medicare ID (if it wasn’t supplied on the
original add record), a delete transaction should be submitted with the same values in other
fields that were submitted on the original.

7-28
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Example: A record was previously sent to the BCRC and an MSP occurrence posted
indicating that a GHP was a primary payer based on the individual’s current employment
status. Subsequently, it is discovered that the individual was not employed and that Medicare
should have been the primary payer. The original record was sent and posted in error. A
delete transaction is sent on the next quarterly update MSP Input File and the BCRC removes
the MSP occurrence from the CWF or MBD.
Note: Delete transaction only need to be submitted for records that resulted in a ‘01’
disposition code on a previous corresponding response file record. If the record was not
returned with a ‘01’ then an MSP occurrence was not created and there is nothing to delete
from Medicare’s files. In addition, deletes are only to be used to remove an MSP occurrence
created in error. Please review the following information concerning reporting Termination
Dates, correcting and changing information carefully.
How to Report a Coverage Termination Date for Active Covered Individuals
The Coverage Termination Date is the last day that the Active Covered Individual is covered
through a GHP due to current employment (with the exception of situations involving
ESRD). Even though GHP coverage may continue past their last day of employment, (e.g.,
the covered individual stops working mid-month but retains coverage until the end of the
month), the submitted coverage termination date should be the last day that the Active
Covered Individual was employed). Medicare becomes primary payer once current
employment ends.
Example #1:
Covered individual retires on June 10, 2013 but retains GHP coverage until June 30, 2013.
The RRE must submit the last day of current employment (June 10, 2013) in the Coverage
Termination Date (Field 11). Do not submit the day after the last date the beneficiary was
covered by the GHP (July 1, 2013) in the Coverage Termination Date. Medicare
becomes primary on June 11, 2013.
Example #2
Covered individual is entitled to Medicare because of ESRD and is still in the 30-month
coordination period when they stop working on April 15, 2013. They have retained their
GHP coverage until April 30, 2013. Since this individual is entitled to Medicare because of
ESRD and is still in the 30 month ESRD coordination period, the RRE must submit the last
date of GHP coverage (April 30, 2013) in the Coverage Termination Date (Field 11) and not
the last date of current employment (April 15, 2013). Medicare becomes primary payer on
May 1, 2013 because the GHP coverage ceased on April 30, 2013.
When coverage for an Active Covered Individual previously sent and accepted by the BCRC
ends, you must send an update record with the Termination Date (Field 11). The BCRC will
update the MSP occurrence Termination Date and Medicare will become the primary payer
after that date. Do not send a delete transaction in these cases. A delete transaction will
remove the MSP occurrence entirely, as though Medicare was always supposed to be the
primary payer, and claims will be paid erroneously.
Correcting MSP Occurrence Key Information and Information Used to Determine MSP -
When to Send a Delete and Add to Make Corrections
If you need to correct one of the key matching fields used for MSP occurrences (Medicare
ID/SSN, Effective Date, Insurance Coverage Type, or Relationship to Policyholder) or other

7-29
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

information used to determine MSP (Employer Size, Employee Status), you need to follow a
special process to make this update. First, a delete transaction must be sent in your file to
remove the previously added record. The delete transaction should then be followed by an
add transaction in the same file to add the record back, if applicable, with the corrected
information. This process will completely replace the previously added MSP occurrence with
the correct information.
This instruction applies to situations where incorrect information was sent on a previous
record for the follow fields and the record was accepted and returned with an ’01’ disposition
code meaning that an MSP occurrence was created:
• Medicare ID/SSN – Fields 1 or 9 (the wrong person was submitted)
• Effective Date – Field 10
• Coverage Type – Field 8
• Relationship Code – Field 12
• Employer Size – Field 16
• Employee Status – Field 20
If incorrect information was submitted for any of these fields and an MSP occurrence was
created, then it is the RRE’s responsibility to first remove the MSP occurrence and then resend
the record with corrected information on a new add record in order for the BCRC to make a new
MSP determination. If the new information regarding the individual’s coverage results in
him/her not meeting the criteria to be considered an Active Covered Individual, then only a
delete record needs to be sent to remove the erroneous MSP occurrence. No add record is
required if the person is not now considered an Active Covered Individual.
Note 1: RREs only need to correct the Medicare ID/SSN in cases where an incorrect person was
submitted and accepted on the input record. Medicare IDs (HICNs or MBIs) may be changed by
the Social Security Administration at times but the BCRC is able to crosswalk the old Medicare
ID to the new Medicare ID. Therefore, in those instances where the correct person was
previously submitted and the Medicare ID changes for that person at a later date, the RRE does
not need to correct the record. In fact, updates may continue to be sent under the original
Medicare ID/SSN submitted. The BCRC will always return the most current Medicare ID on
response records and RREs are encouraged to update their systems with that information and use
it on subsequent record transmissions.
Note 2: If a record was previously submitted and accepted with only a SSN, and the RRE obtains
the Medicare ID on the response file, the RRE should not send a “Delete” and “Add” to update
the beneficiary’s information with the Medicare ID. The record has already been stored under
both the SSN and Medicare ID by the BCRC. Subsequent transactions for the record must be
submitted with the Medicare ID.
Example 1: A record was previously sent with March 1 as the coverage effective date. The
BCRC returned a disposition code of ‘01’ for the record on the response file and indicated that
the MSP Effective Date on the posted record is March 1. Subsequently it is determined that the
Active Covered Individual’s GHP coverage effective date was actually April 1. A delete
transaction is sent in the next quarterly MSP Input File with March 1 in the effective date. In the
same file, but following the delete transaction, an add transaction is sent with April 1 as the
effective date. The BCRC removes the MSP occurrence with the March 1 effective date and adds
the correct MSP occurrence with an April 1 effective date.

7-30
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Example 2: A record was previously sent with an Employer Size of ‘2’ to indicate that the
employer had 100 or more employees. The BCRC returned a disposition code of ‘01’ for the
record on the response file and posted an MSP occurrence at CWF. Subsequently it is discovered
by the RRE that the Employer Size should have been submitted with a value of ‘1’ since the
employer had less than 100 employees in the previous calendar year but more than 19. A delete
transaction is sent in the next quarterly MSP Input File with the Employer Size of ‘2’. In the
same file, but following the delete transaction, an add transaction is sent with an Employer Size
of ‘1’. The BCRC removes the MSP occurrence previously created and makes a new
determination of MSP based on the corrected Employer Size submitted. The disposition code
returned will depend on the new MSP determination which is based on MSP regulations and the
information submitted on the new add record.
Changing Information Used to Determine Medicare Secondary Payer – When to Send an
Update and Add to Report a Change
The following fields are used, in part, by the BCRC in determining whether Medicare is
secondary to an RRE’s GHP coverage for an individual:
• Coverage Type – Field 8
• Relationship Code – Field 12
• Employer Size – Field 16
• Employee Status – Field 20
If the information for any of these fields changes after an MSP occurrence has been created, do
the following:
• Submit an update transaction with the old values and a termination date reflecting the
last day the information was true.
• Submit an add transaction with the new data values with an effective date equal to the
date the changed value became effective (the day after the termination date in the update
record previously described.)
If the changed information regarding the individual’s coverage results in the beneficiary not
meeting the criteria to be considered an Active Covered Individual since the date the change
occurred, then only an update record needs to be sent to terminate the MSP occurrence. If the
beneficiary expands or reduces their insurance coverage, first terminate the record by
providing an end date and then send an add record with the updated coverage (see next
example). No add record is required if the person is not considered an Active Covered
Individual subsequent to the change.
Example: An add transaction was sent indicating that the Coverage Type was Hospital and
Medical (a value of ‘A’ in Field 8). The Effective Date submitted was January 1 and the
Termination Date was open-ended. The record was accepted and the BCRC created an MSP
occurrence and returned a disposition code of ‘01’. Effective June 1, the coverage for the
individual changed to Hospital Only. In the next quarterly file submission, an update
transaction should be sent with a Coverage Type value of ‘A’, Effective Date of January 1
and a Termination Date of May 31. In the same update file, an add transaction should be sent
with an Effective Date of June 1, an open-ended Termination Date and a Coverage Type of
‘J’ reflecting the new Hospital Only coverage.
Note that this situation differs from the previous discussion of deleting the original record
and adding a new record. In this case the original record was correct, but the information

7-31
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

changed subsequent to the MSP occurrence being posted by the BCRC. If information
changes for fields other than those listed here and MSP occurrence key fields listed
previously, you may simply submit one update transaction with the new information in the
applicable field.
Note: For more information regarding calculating and reporting changes to employer size,
please see Appendix G.
Initial Reporting When Employer Size Reaches 20 and Employer is Not Part of a Multi-
Employer/Multiple Employer Plan
As stated previously, if an employer has less than 20 full and/or part-time employees as
defined in 42 C.F.R. Part 411.101 and 42 C.F.R. Part 411.170, and the employer is not part of
a multi-employer/multiple employer GHP, then the covered individuals under that plan do
not have to be reported under Section 111 unless a covered individual is receiving dialysis or
has had a kidney transplant (ESRD). However, records for all Active Covered Individuals in
these plans may be submitted with the proper value in the Employer Size (Field 16). If
reported and the BCRC determines that MSP does not exist, then an SPES error code will be
returned as explained in a later section of this guide.
If coverage was not previously reported for any individuals due to the employer size being
less than 20 employees, and subsequently the number of employees increases to 20 or more,
the affected covered individuals must be reported on add records if they meet the other
requirements to be included on the MSP Input File. When these add records are submitted,
you must use the later of the effective date of the new employer size or the individual’s GHP
coverage effective date in Field 10 (Effective Date) of the MSP Input File Detail record
rather than simply the effective date of the individual’s GHP coverage. This will ensure that
the BCRC creates an MSP occurrence starting at the date that Medicare becomes the
secondary payer.
See Appendix G for more information on Employer Size.

7.2.6.2 Quarterly Update Event Table

The following table provides a summary of the events to be considered when creating a quarterly
update MSP Input File for ongoing Section 111 reporting. It is to be used by RREs and their
agents to determine when and how to send records on a quarterly MSP Input File after the initial
MSP Input file has been successfully processed. RRE Actions reflect MSP Input File record
submissions to be included in the next quarterly submission after the event occurs. Please see the
MSP Input File requirements in other sections of this guide and record layouts in Appendix D for
the requirements for each specific field on the record as this table describes the record
submission only in general terms. The phrase “previously reported and accepted” means that an
MSP Input Detail record was previously submitted and the BCRC sent back a disposition code of
‘01’ on the corresponding MSP Response File record. A complete explanation of the disposition
codes returned can be found in a later section of this guide and in Appendix D.

7-32
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Table 7-3: Quarterly Update Event Table

Event RRE Action
Initial Report of New GHP Coverage Send Add Record:
• New enrollee (subscriber/dependent) • ‘0’ (add) in the Transaction Type (Field 7)
• New Active Covered Individual/Medicare • All other fields as specified in Appendix A
Beneficiary • Refer to all other requirements for MSP Input File
reporting
Termination of GHP Coverage Send Update Record:
• MSP record with an open-ended • ‘2’ (update) in the Transaction Type
termination date previously reported and • Date GHP Coverage ended in Termination Date
accepted by the BCRC (Field 11). Submit the last day that the Active
• GHP for the Medicare beneficiary ends Covered Individual is covered through the GHP
due to current employment (with the exception of
situations involving ESRD).
• All other fields as previously reported on the
initial add record as specified in Appendix A
Key Field or Field Used in MSP Determination Send a Delete Followed by an Add in the same file
Correction – Delete/Add Send Delete Record:
• MSP record was previously reported and • ‘1’ (delete) in the Transaction Type
accepted
• All other fields with matching values sent on the
• Incorrect key field/MSP field information original record
was originally submitted. One or more of
Send Add Record:
the following fields was corrected after the
initial MSP record was submitted and • ‘0’ (add) in the Transaction Type
accepted: • Corrected/updated information for all other fields
• Medicare ID (Field 1) or SSN (Field
9) – an incorrect person was
originally identified
• Effective Date (Field 10)
• Coverage Type (Field 8)
• Relationship Code (Field 12)
• Employer Size (Field 16)
• Employee Status (Field 20)
Changed MSP Information – Update/Add Send an Update Followed by an Add
• MSP record was previously reported and Send Update Record:
accepted • ‘2’ (update) in the Transaction Type
• One or more of the following fields used to • Last date the information was true in Termination
determine MSP was subsequently changed Date (Field 11)
after the initial MSP record was submitted
and accepted: • All other fields with matching values sent on the
original record
• Coverage Type (Field 8)
Send Add Record:
• Relationship Code (Field 12)
• ‘0’ (add) in the Transaction Type
• Employer Size (Field 16)
• Effective Date of the changed information in the
• Employee Status (Field 20) Effective Date (Field 10). This should be the day
after the Termination Date supplied on the update
record.
• Updated information for all fields

7-33
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Event RRE Action

Other Changed Information (other than Key Field Send Update Record:
or information used to determine MSP) • ‘2’ (update) in the Transaction Type
• MSP record was previously reported and • Values that match the original accepted record in
accepted key fields and other information used to determine
• One or more of the fields on the MSP Input MSP
Detail Record has changed other than the • Changed values for affected fields
key fields and those used to determine MSP
as specified above
Delete/Cancel Prior Record Submission Send Delete Record:
• MSP record was previously reported and • ‘1’ (delete) in the Transaction Type
accepted • All other fields with matching values sent on the
• Record was submitted in error – it should original record
not have been sent due to an RRE system
problem or other issue
Record Rejected with Errors Correct errors:
• Submitted MSP record returned with an • Send record with previously submitted
‘SP’ disposition code in the corresponding Transaction Type (Add, Update or Delete)
response file record (not accepted, rejected
by the BCRC due to errors)
Record in Process at BCRC Resubmit same record
• Submitted MSP record returned with a
’50’, ‘52’, ‘53’, ‘61’, ‘AB’, or ‘CI’
disposition code in the corresponding
response file record (still being processed
by the BCRC)
Ongoing Monitoring of Active Covered Send Add Record:
Individuals • ‘0’ (add) in the Transaction Type
• MSP record previously submitted and • Send record with current information according to
rejected by the BCRC with a ‘51’ specifications in Appendix A
disposition code
OR
• GHP coverage for the individual continues
• Monitor using the query function (finder file) and
• Individual meets definition of Active send add once identified as Medicare beneficiary
Covered Individual
Change in TIN Name or Address Send updated TIN Reference File:
• MSP record was previously reported and • Send updated TIN Reference File for affected
accepted TINs with updated name and/or address fields
• Name or address information changes for
the Employer or Insurer TIN submitted in Send Update Records for all matching MSP Input File
Field 21 or 22 Records:
• ‘2’ (update) in the Transaction Type
• All other fields with matching values sent on the
original record. This will associate the new
name/address with the MSP occurrence.

7-34
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Event RRE Action

Request Small Employer Exception (SEE) for Send Delete Record:
Previously Posted MSP Occurrence • ‘1’ (delete) in the Transaction Type
• MSP record was previously reported and • All other fields with matching values sent on the
accepted. No SEE Medicare ID (Field 32) original record. Do not include SEE Medicare ID
submitted. (HICN or MBI) on the delete record.
• RRE subsequently determines that an Send Add Record:
approved SEE applies to the previously
• ‘0’ (add) in the Transaction Type
reported GHP coverage period.
• Current information for all fields. Include SEE
Medicare ID (Field 32).

7.2.6.3 MSP Input File Reporting Helpful Reminders

The following list includes some helpful reminders for RREs to consider when submitting MSP
Input Files.
• Do not include GHP coverage related to a retirement plan on your MSP Input File, when
coverage for the Active Covered Individual is not due to the current employment status of
the subscriber/employee, unless the reported individual is likely to be entitled to
Medicare due to ESRD.
• Always make sure the Employee Status (Field 20) reflects the correct employment status
of the subscriber/employee when you are reporting GHP coverage for the subscriber or
a dependent. Field 20 applies to the subscriber/employee who is not always the Active
Covered Individual or beneficiary for which coverage is being reported.
• You must include the Medicare ID (HICN or MBI) for individuals under age 45 on MSP
Input File Detail Records. The Medicare ID can be obtained directly from the beneficiary
or by making use of the Query Only Input/Response File or the Beneficiary Lookup
feature on the Section 111 COBSW.
• If an Active Covered Individual has a combination of hospital, medical, and prescription
drug coverage under the GHP, make use of one of the comprehensive Coverage Type
codes (Field 8) such as A, W or 4. A beneficiary should never have two MSP
occurrences, for the same time period, for the same type of coverage, under the same
GHP insurer. Do not submit separate, multiple records for hospital and medical coverage
(e.g., Coverage Type J and K) unless the hospital and medical coverage are under
separate GHPs with different insurers. If coverage for the beneficiary changes (e.g., from
comprehensive hospital/medical to hospital only or medical only) submit an update
record with a termination date for the previous coverage record and an add record that
reflects the new Coverage Type with the associated effective date of that change.
• Delete transactions should only be submitted to 1) remove an entire record that was
created in error or 2) correct a key field as specified in the Event Table.
• Make sure that Termination Dates reflect the last day of the coverage reported rather than
the day after. Effective and Termination Dates are to reflect a coverage period “through
and including” the reported dates not “up to but less than” the Termination Date. For
example, if coverage ends at the end of the month of October, then report October 31 in
the Termination Date, not November 1.

7-35
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

• RREs are encouraged to pre-validate employer and insurer/TPA addresses using postal
software or online tools available on the USPS website pages, such as:
https://tools.usps.com/go/ZipLookupAction!input.action.
• When submitting new or updated information on TIN Reference Records, be sure to also
submit updates for MSP records previously submitted and accepted that have the
matching insurer or employer TINs on the MSP Input File. In order to associate new TIN
name and address information to an existing MSP occurrence, you must not only submit
the TIN Reference File record but also resubmit the associated MSP Input File record.

7.2.7 MSP Input File Detailed Requirements

• MSP Input Files must contain properly formatted header, detail and trailer records as
defined in Appendix A.
• MSP Input Files must be submitted on a quarterly basis, four times a year, unless an RRE
has nothing to report for a particular quarter.
• Files must be submitted within your assigned, 7-day submission period each quarter. The
receipt date of your file will be set to the date the BCRC batch system processes it. The
BCRC runs batch processes nightly Monday – Friday excluding holidays. As batch
processing may cross midnight, the receipt date may not be defined until the day after
transmission by the Section 111 RRE. Files submitted on weekends will be held and not
processed until the Monday night batch cycle. If your receipt date falls after your 7-day
submission timeframe, your file will be processed but will be marked as late on
subsequent compliance reports.
• New Section 111 RREs are to complete registration on the COBSW at least one quarter
in advance of having production data to report for Section 111 in order to allow for
adequate time to test the file submission process prior to the start of production file
reporting.

7.2.7.1 MSP Initial Input Files

• RREs’ initial MSP Input File submissions must report on all Active Covered Individuals
or Active Covered Individuals identified as Medicare beneficiaries through the query
process , who had open coverage under you GHPs and regardless of the assigned date for
a particular RRE’s first submission. However, if the GHP coverage effective date is
within 45 days prior to the start of your 7-day file submission timeframe, you may submit
that information on your next quarterly file (the following quarterly file submission
period). This grace period allows you time to process the new enrollee information
internally prior to submission for Section 111. Records not received on time will be
processed but marked as late and used for subsequent compliance tracking.
See special instructions for HRA reporting below.
• A TIN Reference File must be submitted prior to or with the Initial MSP Input File,
containing records for each TIN submitted in Fields 21 and 22 of the MSP Input File.

7.2.7.2 MSP Subsequent Quarterly Input Files

• Subsequent MSP Input Files do not need to be accompanied by a TIN Reference File
unless there are changes to TIN information previously submitted or new TINs have been
added.

7-36
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

• All TINs (or EINs) on the MSP Input File records must have a valid corresponding TIN
record on the TIN Reference File.
• Subsequent quarterly update files must include records for any Active Covered Individual
(or an Active Covered Individual identified as a Medicare beneficiary through the query
process) that you have added to your plan since the last file submission. However, if the
coverage effective date is within 45 days prior to the start of your 7-day file submission
timeframe, then you may submit that information on your next quarterly file. This grace
period allows you time to process the new enrollee information internally prior to
submission for Section 111.
For example, if an Active Covered Individual’s GHP coverage effective date is May 1,
2019, and your file submission period for the second quarter of 2019 is June 1-7, 2019,
then you may delay reporting that individual until your third quarter file submission
during September 1-7, 2019. However, if the individual’s GHP coverage effective date is
April 1, 2019, then you must include this individual on your second quarter file
submission during June 1-7, 2019.
Records not received timely will be processed but marked as late and used for subsequent
compliance tracking.
• Subsequent quarterly update files must include updates to any previously submitted
record that has changed since the last submission.
• Quarterly update files must contain resubmission of any records found in error on the
previous file (Disposition Code of SP) with corrections made. Please refer to the
Processing Response Files Section 7.2.8 for more information.
• Quarterly update files must contain resubmission of any records that received the
Disposition Codes ‘ID’ or ‘51’ on the previous response file, if the individual is still
covered and is an Active Covered Individual (or an Active Covered Individual identified
as a Medicare beneficiary through the query process), with corrections applied as needed.
Please refer to the Processing Response Files Section 7.2.8 for more information.
• RREs are NOT to submit full-file replacements for the MSP Input File each quarter. You
must process your MSP Response File per the instructions in this user guide. You must
submit add, update and delete transactions according to the instructions in this user guide.
RREs who continue to submit full-file replacements or send the same records repeatedly,
regardless of the disposition codes returned on the MSP Response File or regardless of
whether the individual meets the definition of an Active Covered Individual, are
considered non-compliant with Section 111 Mandatory Reporting Requirements. Full file
replacements are acceptable for submission of the TIN Reference File.
• If you have no new information to supply on a quarterly update file, you may submit an
“empty” MSP Input File with a header record, no detail records, and a trailer record that
indicates a zero-detail record count. RREs are not required to submit empty files if they
have nothing to report for a particular quarter. Empty files will be accepted but are not
required. Response Files are not returned for empty file submissions.
• Email notifications will be sent to the Account Manager assigned to the RRE ID after a
file has been received, and when a response file has been transmitted or is available for
download.
• Each detail record on the MSP Input File must contain a unique Document Control
Number (DCN) generated by the RRE. This DCN is required so that response records can
be matched and issues with files more easily identified and resolved. It can be any format

7-37
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

of the RREs choosing as long as it is not more than 15 text characters as defined in the
record layout. The DCN only needs to be unique within the current file being submitted.
Records may be submitted with the same DCN in subsequent file submissions as long as
they are unique within the file submitted.
• Employer size (the number of full or part-time employees, not the number of covered
lives under a particular GHP) is critical to determining primary vs. secondary payment
responsibility. RREs must report all Active Covered Individuals for all employers who
are part of a multiple/multi-employer GHP regardless of the number of full or part time
employees for a particular employer. RREs must have employer size information for all
of the employers in a multiple/multi-employer GHP. Employer size must be reported on
each MSP Input File record in Field 16. If the employer is part of a multi-employer plan,
this field should reflect the size of the largest employer in the plan. Refer to 42 C.F.R.
Part 411.101 and 42 C.F.R. Part 411.170 for details on the calculation of employer size.
Additional information can be found at
https://www.cms.gov/manuals/downloads/msp105c01.pdf. All Medicare manuals can be
found at https://www.cms.gov/regulations-and-guidance/guidance/manuals/internet-only-
manuals-ioms.html. The MSP Manual is publication 100-05. See Appendix G for more
information on calculating employer size.
• Employer size must be based on the size of the entire company or corporation, not just
the subsidiary. When calculating the number of employees, RREs should use the total
number of employees in an organizational structure (parent, subsidiaries and siblings)
rather than just the number of employees in the particular subsidiary being reported on.
Subsidiaries of foreign companies must count the number of employees of the
organization worldwide. Refer to 42 C.F.R. Part 411.101 and 42 C.F.R. Part 411.170 for
details on this calculation. Additional information can be found at
https://www.cms.gov/manuals/downloads/msp105c01.pdf. All Medicare manuals can be
found at https://www.cms.gov/Regulations-and-Guidance/Guidance/Manuals/Internet-
Only-Manuals-IOMs.html on the internet. The MSP Manual is publication 100-05.

7.2.7.3 About FSAs, HSAs, and HRAs

• A Flexible Spending Account (FSA) product is not considered to be GHP coverage for
MSP purposes. RREs are not required to include FSA programs in Section 111 reporting.
• A Health Savings Account (HSA) is typically associated with a high deductible GHP
product. Under current law, Medicare beneficiaries may not make further contributions to
the savings portion of an HSA, although they retain access to previous contributions, both
their own and those made by an employer. The CMS will not consider HSAs to be
reportable under Section 111 as long as Medicare beneficiaries may not make a current
year contribution to an HSA or did not make a contribution during the time he or she was
a Medicare beneficiary.
• A Health Reimbursement Arrangement (HRA) is a GHP arrangement and is subject to
the MSP reporting provisions. HRAs include Individual Coverage HRAs (ICHRAs).
ICHRAs can be used to pay both premiums and medical claims. All HRAs, including
ICHRAs, Qualified Small Employer Health Reimbursement Arrangements (QSEHRAs),
and excepted benefit HRAs, are subject to the applicable MSP provisions regardless of
whether or not they have an end-of-year carry-over or roll-over feature. An HRA is
funded 100% by an employer.

7-38
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

• HRA coverage should be reported in the RRE’s regular quarterly MSP Input File
which is submitted during the file submission timeframe assigned to the applicable
RRE ID. Since future dates cannot be accepted in the Effective Date Field of the
MSP Input File, HRA coverage should be reported by all HRA RREs as soon after
the effective date of the coverage date as allowed by the RRE’s file submission
timeframe.
• Only HRA coverage that reflects an annual benefit value of $5,000 or more that is
available to a specific Medicare beneficiary to pay medical claims is to be reported.
HRAs with an annual benefit amount of less than $5,000 that is available to the
specific Medicare beneficiary to pay medical claims are exempt from reporting.
Amounts rolled over from the previous plan year’s coverage must be included when
calculating the current year’s annual benefit value. Note: The new $5,000 Annual
Benefit Reporting Threshold applies to all new or renewing HRA coverage which
became effective on or after October 3, 2011. RREs reporting existing coverage will
continue to do so at the present threshold ($1,000) until the employer’s HRA benefit
period is renewed.
• Termination Dates are to be submitted when the covered individual loses or cancels
coverage, or when the annual benefit value to pay medical claims is exhausted and no
additional funds will be added to the HRA for the remainder of the HRA’s current
benefit coverage term. Note: Notice of the termination is to be provided to the BCRC
by including it in the RRE’s next regularly scheduled MSP Input File submission.
The RRE may also call the BCRC Call Center, at 1-855-798-2627 (TTY/TDD: 1-
855-797-2627), with notice of the termination.
• Once the GHP HRA benefit period is renewed, the RRE must submit a new add
record on the MSP Input File for each Medicare beneficiary that is an Active Covered
Individual and whose HRA annual benefit is $5,000 or greater to pay medical claims.
The Effective Date (Field 10) should reflect the start date of the new coverage period.
• If reportable HRA coverage continues year to year, then the record may be reported
with an open-ended Termination Date as is done with non-HRA GHP coverage
reporting. A Termination Date should not be reported unless the HRA coverage is not
continued or not renewed in the subsequent year.
• HRA coverage is to be reported using a value of ‘R’ in Coverage Type
(Field 8) in MSP Input File Detail Records, and with a value of ’Z’ in Coverage Type
(Field 22) in Non-MSP Input File Detail Records.
• HRA coverage is reported in addition to other applicable GHP coverage.
Consequently, an RRE may need to submit two MSP Input File Detail records for an
individual, one for the HRA using Coverage Type ‘R’ and the other for the
“standard” GHP coverage using the applicable value for that in the Coverage Type
field.
• Routine dental services, dentures, acupuncture, chiropractic services, cosmetic surgery,
routine hearing examinations and hearing aids are not covered benefits in the Medicare
program. Medicare does cover inpatient hospital services required in dental services.
Routine vision care is also not a covered Medicare benefit, although Medicare does cover
periodic eye exams to check for the presence of diabetic retinopathy and will pay for one
pair of glasses after one particular type of cataract surgery. When offered as stand-alone
products or “carve-outs,” dental, acupuncture, chiropractic services, routine hearing
exams, hearing aids and vision care GHP coverage are not to be included in Section 111
7-39
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

reporting. However, RREs are responsible for being aware of situations where services
are covered by Medicare and pay primary to Medicare for all beneficiaries who have such
stand-alone coverage when appropriate.
• Behavioral/mental healthcare services are generally not covered benefits in the Medicare
program. When offered as stand-alone products or “carve-outs”, behavioral and/or mental
healthcare GHP coverage is not to be included in Section 111 reporting. However, RREs
are responsible for being aware of situations where healthcare services are covered by
Medicare and pay primary to Medicare for all beneficiaries who have such stand-alone
coverage when appropriate.
• Information concerning an individual’s coverage under TRICARE or a Medicare
Advantage plan (Part C) should not be included on the MSP Input File. TRICARE
coverage is always secondary to Medicare, Medicare is the primary payer. Medicare
Advantage is a form of Medicare coverage, so it does not apply to MSP determinations.
• CMS recommends that RREs send a covered individual’s Medicare ID (HICN or MBI)
on MSP Input File records whenever it is available. The Medicare ID is also known as
the Medicare Number to CMS’ Medicare beneficiaries. It is CMS' identifier for Medicare
beneficiaries and is the preferred data element for matching purposes. RREs are
encouraged to obtain Medicare IDs from Medicare beneficiaries they cover for initial
reporting. RREs must use the Medicare IDs passed back to them by the BCRC on
response files on all subsequent transactions for the beneficiary.
Note: If you submitted a record initially using a HICN and it was accepted, and then
updated it to an MBI, then use the MBI with future updates.
• Special Note for Religious Orders: Members of religious orders who have taken a vow of
poverty may be exempt from the MSP provisions. This exemption is only applicable
for work being performed as an employee of the religious order and where the
religious order is providing the GHP coverage. If GHP coverage is provided by any
entity other than the order (e.g., a school in which the member teaches or a hospital
in which the member works) the exemption does not apply. RREs are not to report
GHP coverage on the MSP Input File when the coverage is provided by the religious
order for individuals who have taken a vow of poverty and the coverage meets the
conditions of this exemption. For further information on religious order exemptions, refer
to the Medicare MSP regulations as cited in Chapter 5.

7.2.8 Processing MSP Response Files

For every non-empty MSP Input File, you send to the BCRC for Section 111 reporting that is
successfully transmitted without severe errors, the BCRC will send you a response file in return.
The MSP Response File specifications are in Appendix A. The response file will be transmitted
back to you within 45 days of receipt of your input file, in the same manner you used to send
your input file. The response file contains a header record, followed by detail records for each
record you submitted on your input file, followed by a trailer record that contains a count of the
detail records supplied. This count does not include the header and trailer records. In some cases
(as explained in Section 7.2.8.8) you may receive more than one detail record for the input
records you sent, but ordinarily it will be a one for one exchange. The response file detail records
consist of the same data elements in the input file you sent, with updated Medicare information
applied by the BCRC, the disposition and error codes which let you know what the BCRC did
with the record, as well as new information, such as Medicare entitlement and enrollment data,
regarding the covered individuals themselves.

7-40
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

You must develop processing to react to the response file. Your response file for a given
quarterly report must be processed before submission of your subsequent quarterly MSP Input
File. Disposition, SP and Rx error codes, TIN Reference error codes are documented in
Appendix D.

7.2.8.1 Disposition Codes

Every MSP Input File record will receive a disposition code on the corresponding response file
record, and you must take the following actions:
• Records marked in error with an ‘SP’ disposition code must be corrected as specified in
the error code description in Appendix D and resent on your next quarterly submission.
Note that most errors require a correction on the part of the RRE but certain others do
not.
• If a record was rejected with a disposition code of ‘51’, which indicates the Active
Covered Individual could not be matched to a Medicare beneficiary, you must continue to
resend current information for this individual in subsequent quarterly file submissions
until it is accepted, your coverage for this individual is terminated, or the individual no
longer meets the definition of an Active Covered Individual (e.g., employment ends,
retirement, etc.). Alternatively, you may use the query process to monitor the Medicare
status of the individual and resubmit the MSP Input File Record only after determining
the individual is covered by Medicare and remains an Active Covered Individual.
• A disposition code of ‘51’ will also be returned if neither a valid Medicare ID (HICN or
MBI) nor SSN is submitted on the input record. You must obtain a valid Medicare ID or
SSN for the Active Covered Individual and resubmit the record on your next quarterly
file submission.
• Records accepted with a ‘01’ disposition code have been added by the BCRC as coverage
primary to Medicare in the form of an MSP occurrence on the Medicare CWF or MBD
and will be used in Medicare claims processing to make sure Medicare pays secondary.
The following fields may contain updated information from the BCRC based on
Medicare’s information and should be used to update your internal files:
• Medicare ID
• Active Covered Individual/Beneficiary Name
• Date of Birth
• Gender
Note: You must store the Medicare ID returned on the response file in your internal
system and are required to use it on future transactions.
In addition, records returned with a ‘01’ disposition code will contain the following
information which you may use in your claims processing for coordination of benefits
and proper claim processing:
• MSP Effective and Termination Dates – start and end dates for the period of time your
coverage overlaps Medicare coverage, your coverage is primary to Medicare and should
pay first. Note that in some cases, the MSP Effective Date may reflect a future date based
on an established Medicare entitlement date in the future.
• Medicare Part A, B, C, and D Coverage Dates – As of July 2019, Part D enrollment
information will be returned to those who report primary prescription drug coverage.

7-41
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

• End Stage Renal Disease (ESRD) information

Records that are rejected with any other disposition code must be resubmitted on your next
quarterly update file. As a rule, you should check these records for accuracy, update the
information previously sent, as applicable, and resubmit.
Note that since the age threshold for Active Covered Individuals is 45 but most people are not
entitled to Medicare until they are 65, you will receive a significant number of records back with
disposition ‘51’ each quarter. This is a completely acceptable situation and you should continue
to send current information for these individuals with each quarterly submission until you
receive a ‘01’ disposition code, the GHP coverage is terminated or the individuals no longer fit
the definition of Active Covered Individuals.

7.2.8.2 SP Error Codes

In Appendix D, all possible SP error codes are listed for reference. In the table, each error code is
marked as “RRE Responsible” or “BCRC Responsible”. There are some errors that an RRE
cannot fix, such as those related to conflicting data on internal Medicare databases.
Since the BCRC must send records to other Medicare databases to post the MSP occurrences,
errors beyond your control can occur. Usually the BCRC corrects these errors before creating
and sending your response file. At times though, due to the requirement to send a response file
back to an RRE within 45 days, a response file might be sent back to you before these errors can
be properly addressed. Thus, on rare occasions you may see such an error on your response file,
accompanied by an SP disposition code. When this occurs, correct any other errors that are your
responsibility and resend the record on your next quarterly submission.
Special Consideration for the SPES Error Code
On the MSP Input File, you are asked to submit a code in Field 16, Employer Size, to reflect
the size of the employer sponsoring the GHP associated with each Active Covered
Individual. A value of zero indicates the employer has less than 20 employees; a value of 1
indicates 20 to 99 employees and a value of 2 indicates the employer has 100 or more
employees. This is not a simple count of current employees. Refer to Appendix G for more
information on how to calculate the values for Employer Size.
The BCRC uses the value provided in the Employer Size field when determining whether the
GHP coverage is primary to Medicare and thus establishing MSP occurrences. In some cases,
an MSP occurrence is not created. For example, if an employer has less than 100 employees
and the beneficiary is entitled to Medicare due to disability, Medicare will be the primary
payer in any case and an MSP occurrence will not be created. (Note: If the employer is part
of a multi-/multiple employer plan, Medicare is secondary if any employer in the plan has
100 or more employees.) When the BCRC determines that Medicare is the primary payer for
the GHP coverage reported, it will return a disposition code of SP and put ‘SPES’ in one of
the SP error code fields on the corresponding response file record.
Usually when processing an ‘SP’ disposition code, you are to correct all errors and resubmit
a record in your next quarterly response file. The SPES error code requires special handling
and is an exception to this general rule.
When you receive an SPES error on a response file record, check that the employer size
submitted was correct, update it if the employer size was submitted incorrectly, and continue
to resend the record on all subsequent quarterly file submissions until the individual is no
longer covered by your plan or a ‘01’ disposition code is returned. Since the employer size

7-42
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

may not change, you may continue to receive a response record back with an SP disposition
and SPES error code for these situations. However, you should continue to send these records
in case the reason for the beneficiary’s entitlement to Medicare changes (i.e. from disability
to age) which may affect the MSP determination. As an alternative, the query process could
be used to monitor the Medicare status of these individuals and resend the MSP Input File
Detail Record as appropriate.
Special Consideration for Non-Overlapping GHP and Medicare Coverage
If the Active Covered Individual you submit on an MSP Input File add record is not found to
be a Medicare Beneficiary, you will receive a disposition code ‘51’ back on your response
file. However, if the individual is a Medicare beneficiary but your GHP coverage does not
overlap Medicare coverage because it ended prior to Medicare enrollment, no MSP
occurrence will be built. For example, the GHP coverage may be from 1/1/2012 to 3/31/2012
and Medicare coverage begins on 4/1/2012. In this particular situation, you will receive a
disposition code of SP with a SP error code of SP32 or SP62 indicating you sent an invalid
termination date or an SP75 indicating that the beneficiary did not have Medicare Part A
entitlement during your GHP coverage period. Of course, you cannot change the dates of
your GHP coverage arbitrarily to “fix” this error. On an add record, you may ignore the error,
and if the individual is no longer considered to be an Active Covered Individual because he
or she is no longer covered by your plan, discontinue sending a record for him or her on
subsequent quarterly file submissions. If the individual is still an Active Covered Individual,
you must continue to send the record on subsequent files or monitor his or her Medicare
status via the query process.
An SP32 error will also be returned when you submit an update record to post a termination
date to a previously accepted open-ended record and the termination date on the update is
prior to the beneficiary’s date of Medicare entitlement. For example, this circumstance may
occur if an employer is late in reporting a termination date to the insurer RRE. In this case,
since the GHP coverage ended prior to Medicare entitlement, Medicare is primary, and no
MSP occurrence should exist for the GHP coverage. In order to remove the MSP occurrence,
send a delete transaction with the same effective date and zeroes in the termination date.
In all other cases, if you receive a SP32 or SP62 error, then you most likely submitted an
actual invalid date that needs to be corrected, and the record must then be resubmitted. Please
see the description of SP error codes in Appendix D.
Special Consideration for the SP99 Error Code
If an RRE submits an MSP Input File Detail record for a covered individual under age 45
without supplying a Medicare ID (HICN or MBI) on that record, then the record will be
rejected with an ‘SP’ disposition code and an ‘SP99’ error code. The BCRC will not attempt
to match this record to Medicare beneficiary information. A record submission of this kind
will not protect an RRE from the risk of non-compliance with Section 111 reporting
requirements as the BCRC will not retain a record of this submission since it is considered to
be submitted in error. If an RRE needs to submit GHP coverage information for a Medicare
beneficiary under age 45, the RRE must first obtain the Medicare ID for the beneficiary.
This can be done by obtaining the information directly from the Medicare beneficiary. To
view and download the “Collection of Medicare Health Insurance Claim Numbers (HICNs),
Social Security Numbers (SSNs) and Employer Identification Numbers (EINs) (Tax
Identification Numbers)” alert, go to the Downloads section of the GHP web page at:
https://go.cms.gov/mirghp.

7-43
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

As an alternative, the RRE may submit a query record for this individual. If the information
is matched to a Medicare beneficiary, the query response record will be returned with the
current Medicare ID for the beneficiary, which then can be used to properly submit the
applicable MSP Input File Detail Record. Reporting of individuals under the age threshold is
only necessary for Active Covered Individuals under age 45 known to be Medicare
beneficiaries, not all covered individuals under the age threshold. The Beneficiary Lookup
feature on the Section 111 COBSW may also be used to submit an online query of Medicare
status (see Chapter 9).

7.2.8.3 Rx Disposition and Rx Error Codes

Prescription drug information can be sent as part of a combined coverage record with hospital
and/or medical coverage (Input Field 8 Coverage Types W, X, Y, 4, 5, 6) or as a separate
coverage record for drug-only (Input Field 8 Coverage Types U, V and Z). Records that contain
information for both hospital/medical coverage and prescription drug coverage will receive one
response record. The status of the hospital/medical coverage period will be provided in the
disposition code field (Response Field 8) and the status of the drug coverage period will be
provided in the Rx disposition code field (Response Field 69). If the input record contains drug
coverage information only, then the disposition code in Field 8 will be spaces and the disposition
of the drug coverage record will be in Response Field 69. This is due to the fact that MSP
occurrences for hospital/medical coverage are stored on a different Medicare system database
(CWF) than the MSP occurrences for prescription drug coverage (MBD).
The matching criterion for an MSP occurrence for prescription drug coverage that is primary to
Medicare Part D is:
• Medicare ID (HICN or MBI)
• MSP Effective Date (later of GHP drug coverage effective date or Part D Enrollment
Date)
• Patient Relationship Code (self, spouse, dependent, etc.)
• Section 111 RRE ID (supplied on your header record)
• Insurance Coverage Type (Comprehensive hospital/medical/drug, Drug Only Network
Drug, etc.)
The BCRC will need to match on these fields when processing update and delete transactions for
drug coverage records later.
The Rx Disposition Code (Response Field 69) provides you information regarding what was
done with the prescription drug information you sent. The Rx Error Codes (Response Fields 71-
74) are specific to the prescription drug coverage data elements on the MSP Input File including
Rx Insured ID (Field 24) Rx Group (Field 25), Rx PCN (Field 26), Rx BIN (Field 27), Toll-Free
Number (Field 28) and Person Code (Field 29). Drug records may also have errors for the non-
drug-specific fields in the regular error codes found in Response Fields 40-43.
To process a response record for an input record that contains only hospital/medical information
(Coverage Types A, J, K and R), you must examine:
• The disposition code in response field 8
• The error codes in response fields 40-43
To process a response record for an input record that contains drug and hospital and/or medical
information (Coverage Types W, X, Y, 4, 5, and 6), you must examine:

7-44
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

• The disposition code in response field 8

• The error codes in response fields 40-43
• The Rx disposition code in response field 69
• The Rx error codes in response fields 71-74
To process a response record for an input record that contains only drug information (Coverage
Type U, V and Z), you must examine:
• The error codes in response fields 40-43
• The Rx disposition code in response field 69
• The Rx error codes in response fields 71-74
Every MSP Input File record containing drug coverage information will receive an Rx
disposition code on the corresponding response file record and you must take the following
actions:
• Drug records marked in error with an ‘SP’ Rx disposition code must be corrected and
resent on your next quarterly submission.
• If a drug record was rejected with a Rx disposition code of ‘ID’ or ‘51’ which indicate
the Active Covered Individual could not be matched to a Medicare Beneficiary, you must
check the information you sent for accuracy and then continue to send current
information for the individual until it is accepted or this individual is no longer an
Active Covered Individual.
• Drug records accepted with a ‘01’ Rx disposition code have been added by the BCRC as
drug coverage primary to Medicare in the form of an MSP occurrence on the Medicare
MBD and will be used in Medicare claims processing to make sure Medicare pays
secondary. The following fields may contain updated information from the BCRC and
could be used to update your internal files:
• Medicare ID (HICN or MBI)
• Active Covered Individual/Beneficiary Name
• Date of Birth
• Gender
Note: You must store the Medicare ID returned on the response file in your internal
system and are required to use it on future transactions.
In addition, drug records returned with a ‘01’ Rx disposition code will contain the
following information which you may use in your claims processing for coordination of
benefits and proper claim processing:
• MSP Effective and Termination Dates – start and end dates for the period of time
your coverage is primary to Medicare and should pay first.
• Medicare Part A, B, C, and D Coverage Dates – As of July 2019, Part D enrollment
information will be returned to those who report primary prescription drug coverage.
• End Stage Renal Disease (ESRD) information
• Records that are rejected with an Rx disposition code other than those listed above must
be resubmitted on your next quarterly update file. As a rule, you should check these
records for accuracy, update the information previously sent as applicable, and resubmit.

7-45
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Note: Section 111 RREs who receive RX 07 error codes when submitting drug records
for beneficiaries who have not yet enrolled in a Medicare Part D plan can resubmit
records that received this error on your first file submission of the next calendar year or
monitor the individual’s Medicare Part D enrollment status by logging in to the Section
111 COBSW portal and using the Beneficiary Lookup Tool.
Please make note that there are Special Enrollment Periods (SEPs) that can make a
Medicare beneficiary qualify for Part D. It is the RRE's responsibility to ensure correct
reporting.

7.2.8.4 Part D Eligibility and Enrollment Data

The MSP Response Files contain five related fields that can have information about current
Medicare Part D eligibility and enrollment. Fields 57, 58, and 59 will contain information for
those reporting under the Expanded Reporting Option. As of July 2019, these fields will contain
information for those reporting primary prescription drug coverage under the Basic Reporting
Option. Those fields will be left blank on MSP Response File records for those not reporting
primary prescription drug coverage under the Basic Reporting Option.
Part D Eligibility Start Date (Field 60). This will be the first date a Medicare beneficiary can
enroll in Part D. It is almost always the effective date of coverage for the beneficiary’s Part A or
Part B participation or January 1, 2006 since that was the start date of the Medicare Part D
program. Information in this data field does not show that a beneficiary has enrolled in Part D.
Part D Eligibility Stop Date (Field 61). This is the date that a Medicare beneficiary’s right to
enroll in Part D has ended, for any reason.
Current Medicare Part D Plan Contractor Number (Field 57). This identifies the
beneficiary’s current Part D Plan contractor number.
Current Medicare Part D Enrollment Date (Field 58). This is the effective date of a Medicare
beneficiary’s most recent enrollment in Part D. It is the current first date the beneficiary can
receive Part D benefit coverage.
Current Medicare Part D Plan Termination Date (Field 59). This is the last date a Medicare
beneficiary can receive Part D benefit coverage from the beneficiary’s current Part D plan. After
this date the beneficiary is no longer enrolled and can no longer receive benefit coverage from
the (most recent former) Part D plan.
MSP Response File Fields 58 and 59 tell you whether a beneficiary has actually chosen Part D
coverage, and the period of time the current benefit coverage is in force. For Section 111 RREs,
these two fields are the most immediate indicators of Part D coverage.

7.2.8.5 MSP Input File Threshold and Severe Errors

Threshold Errors
After completion of data quality edits, the BCRC will check your MSP Input File to ensure it
does not exceed any threshold restrictions. Threshold checks are performed to identify a file that
may be in error. In some cases, there could be a reasonable explanation. The file threshold
checks include:
• More than 5% of the total records are delete transactions
• More than 13% of the individuals reported are 79 years old or older

7-46
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

• 20% or more of the total records failed with a disposition code of SP due to errors
• More than one MSP Input File was submitted during your defined quarter.
A file that exceeds the threshold checks will be suspended from further processing until the
suspension is overridden by your EDI Representative. An email will be sent to your Account
Manager to inform him/her of this suspension. You must contact your assigned EDI
Representative to discuss and resolve file threshold errors. Your file may be released for
processing or, if sent in error, deleted by your EDI Representative in which case you may need to
send a corrected file as instructed by your EDI Representative.
Note: The age threshold check is intended to identify a possible situation where an RRE
mistakenly included individuals covered by retirement plans, and not Active Covered Individuals
whose GHP coverage should be primary, to Medicare on the MSP Input File. This is one of the
most common reporting problems and results in mistaken claim denials for Medicare
beneficiaries and requires the RRE to submit delete records to remove erroneous MSP
occurrences. RREs that report a large volume of data for many employer GHPs, may want to run
a similar age threshold check internally for each employer GHP separately since a large volume
of data will mask a problem at the plan level on a file submitted to the BCRC.
Table 7-4 provides some additional information for each threshold error an RRE may receive.
However, RREs must always contact their EDI Representative in the case of a threshold error.

Table 7-4: Threshold Errors

Threshold Error Explanation/Correction
5% or more of records are delete Examine use of the delete function. Do not submit deletes when GHP
transactions coverage ends. Submit updates with termination dates instead. Only
submit deletes to remove erroneous records previously accepted with a
‘01’ disposition code. Very small files may suspend for very few
delete records. If the delete transaction was used correctly, your EDI
Representative will release the file for normal processing.
20% or more of records failed Error messages will display in the threshold email. Contact your EDI
record level edits Representative to discuss most common errors found. Your EDI
Representative will provide further instruction. Very small files may
suspend for very few records in error. In that case, your EDI
Representative may release the file for processing.
Multiple files submitted. Exceeds Only one MSP Input File may be submitted per calendar quarter.
allowed submission frequency. Only one Query Only File may be submitted per quarter. Only one
Non-MSP Input File with N/D records may be submitted per month.
File submitted prior to assigned Files received up to 14 days prior to the start of the RRE’s assigned
submission period file submission timeframe will be considered early and placed in a
hold status. Once the file submission timeframe arrives, the file will be
automatically released for processing. If this file should be processed
immediately, contact your EDI Representative.
Another file in process for/still A file of the same type submitted previously is still processing. This
processing from prior submission prior file must complete processing before the new file can be released
period by your EDI Representative.
Late submission of file File receipt date is after the current submission period. No file
correction is needed. Files must be submitted timely to prevent this
error. Contact your EDI Representative to have the file released for
processing as appropriate.

7-47
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Threshold Error Explanation/Correction

Large number of aged beneficiaries 13% or more of the individuals submitted on the file are age 79 or
older. This may indicate that the RRE included individuals covered by
retirement plans rather than limiting the submission to Active Covered
Individuals (including those over the age threshold covered by current
employment and those diagnosed with ESRD). Review the records
submitted for those over age 65 on the file and verify that they are
truly covered by their own or their spouse’s current employment.
Advise your EDI Representative accordingly. If the file contained
erroneous records, your EDI Representative will delete it and you will
send a corrected file.
File held via watch list Your RRE ID has been put on a watch list by the BCRC due to past
issues with erroneous file submissions. Contact your EDI
Representative to resolve.
Severe Errors
Files detected with severe errors will also suspend from processing. An email will be sent to the
Account Manager for the RRE ID regarding the severe error found. You must contact your EDI
Representative to discuss the situation. The EDI Representative will then delete the file and
provide you with instructions as to when to send a corrected file. Severe errors include:
• Missing or improperly formatted header or trailer records
• Record counts that do not match those actually submitted
The following table provides some additional information for each severe error an RRE may
receive. However, RREs must always contact their EDI Representative in the case of a severe
error.

Table 7-5: Severe Errors

Severe Error Explanation/Correction
File has invalid RECFM/Record Format Files must be submitted in a fixed-block format with all
records of the same fixed length.
File has invalid LRECL/records with invalid The record length of each record on the file must match
record lengths that specified in the record layouts in the appendices. All
unused fields must be set to default values and filler at the
end of the record must be filled with spaces to the end of
the record length.
File empty A file with no header, detail and trailer records was
transmitted to the BCRC. Transmission may have failed or
there was a problem at the RRE with the creation of the
file. If you have nothing to report for a quarter, you may
submit a header record, no detail records and a trailer
record with a zero-record count.
Header record was missing Header record starting with the characters ‘H0’ was not
present prior to encountering a detail or trailer record. Do
not submit detail records with Medicare IDs (Health
Insurance Claim Numbers [HICNs] or Medicare
Beneficiary Identifiers [MBIs]) starting with ‘H0’ or ‘T0’
as these are not valid and might be confused with header
and trailer records.

7-48
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Severe Error Explanation/Correction

Header record does not match filename or The RRE ID on the file header record does not match the
Header record RRE ID does not match mailbox RRE ID under which it was uploaded. The file was
RRE ID uploaded via HTTPS under the wrong RRE ID or sent to
the wrong SFTP mailbox.
Header record not formatted properly Refer to the file layouts in the appendices for proper header
record formats. In particular, the header indicator and file
type must be valid, RRE ID must be numeric with leading
zeroes as appropriate, date fields must contain a valid date
and be formatted as CCYYMMDD.
Trailer record missing No trailer record was found at the end of the file or prior to
the system encountering another header record beginning
with ‘H0’. Do not submit detail records with Medicare IDs
starting with ‘H0’ or ‘T0’ as these are not valid and might
be confused with header and trailer records.
Trailer record not formatted properly Refer to the file layouts in the appendices for proper trailer
record formats. In particular, the trailer indicator and file
type must be valid, RRE ID must be numeric with leading
zeroes as appropriate, date fields must contain a valid date
and be formatted as CCYYMMDD, and the record count
must be numeric with leading zeroes as appropriate.
Trailer record does not match header record The RRE ID and/or file submission dates on the header and
trailer records are not the same.
Trailer record count does not match count of The trailer record count should only include the number of
records in file detail records on the file. Do not include the header and
trailer records in this count.
Test file with more than 100 records Test files must be limited to 100 detail records or less.
Resubmit a new test file with fewer records.
Production file reporter status not equal to P A production file was received for an RRE ID that is not in
a production status. Make sure your profile report has been
signed by your Authorized Representative and returned to
the BCRC. Verify testing requirements have been met. If
so, contact your EDI Representative to request that your
RRE ID be changed to a production status.
Reporter in discontinued/inactive status A test or production file was received but your RRE ID has
been deactivated. File submitted in error. Check to see that
the proper RRE ID was used and that the file was sent to
the proper RRE ID mailbox/dataset. If this RRE ID is still
in use, ask your EDI Representative to correct the status of
your RRE ID.

7.2.8.6 Late Submission Indicator

The MSP Response File contains a Late Submission Indicators that provides information on
issues related to reporting compliance. This indicator is different from an error code. Unlike an
error code, a record will not be rejected if the Late Submission Indicator is set. Instead, the
record is processed, and an MSP occurrence posted if applicable. However, the BCRC will set
the indicator, track this information, and include it on compliance reports. The indicator provides
the RRE notice that the submitted record was not in compliance with Section 111 reporting
requirements. You must apply corrections to your internal system or data used for Section 111
reporting and ensure that records are submitted timely.

7-49
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

The Late Submission Indicator in Field 82 indicates that the submitted record was not sent
timely. It is set to a value of ‘Y’ when the effective date of the covered individual’s GHP
coverage (Field 10 on the incoming MSP Input File) is more than 45 calendar days prior to the
start of the RRE’s prior quarter submission timeframe. If the coverage effective date is within 45
days prior to the start of your 7-day file submission timeframe, then you may submit that
information on your next quarterly file. This grace period allows you time to process the new
enrollee information internally prior to submission for Section 111. Another way to look at it is
that any record received on a quarterly file submission will be marked as late if the effective date
is more than 135 days older than the start date of that same file submission period.
For example, suppose your second quarter file submission timeframe is June 1-7 and your third
quarter file submission timeframe is September 1-7. The start date of your second quarter file
submission is then June 1 and the start date of your third quarter file submission is September 1.
A record with a GHP effective date of April 1 MUST be submitted on your second quarter file
submission since April 1 is more than 45 days older than June 1. If it is received in your third
quarter file submission in September (or later), it will be considered late, and the corresponding
response record will have a ’Y‘ in the Late Submission Indicator field. However, a record with a
GHP effective date of May 1, if received in your third quarter file submission, will not be
marked as late since it is not more than 45 days older than June 1. The record with an effective
date of May 1 may be submitted with your second quarter file submission in June if you have the
information available in your system at that time. If not submitted in June, it MUST be submitted
in your third quarter file submission in September. Note that the BCRC will account for an
individual’s age in this determination. If the individual was not over the age threshold for
reporting on April 1 in the previous example, the Late Submission Indicator will not be set.

7.2.8.7 Split Entitlement Indicator – Multiple Response Records

Medicare entitlement and enrollment can begin, end and then begin again depending on many
factors, which can result in a beneficiary having multiple periods of Medicare coverage. In
addition, the reason for Medicare entitlement can change due to a disabled beneficiary turning
age 65. Due to these multiple periods of coverage and reasons for entitlement, the BCRC may
create more than one MSP occurrence for a period of coverage under your plan. When this
situation occurs, you will receive more than one MSP Response File record for the one Input File
record submitted. Each response record will have a different MSP Effective and Termination
Date depending on the periods of Medicare coverage. Your GHP coverage is primary during the
MSP Effective and Termination Dates and during any periods where there is no Medicare
coverage. Each Response File record will contain a ‘Y’ in the Split Entitlement Indicator
(Response Field 44). Each record will contain your original DCN supplied on the input file
record so you can match them to the original record submitted.
To maintain previously reported GHP coverage which was returned with multiple response
records with Split Entitlement Indicators of ‘Y’, in most cases you could continue to send any
applicable updates and deletes to previously accepted records by transmitting one record with the
original GHP effective date. The system will take that record, look at the beneficiary’s
entitlement, and in the case of split (or dual) entitlement, split the update or delete transaction
and apply it to the two MSP records accordingly.

7-50
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

For example, suppose an MSP Input File Detail Record is sent for GHP coverage effective
1/1/2010 and an open-ended termination date (00/00/0000). The beneficiary was originally
entitled to Medicare due to disability on 1/1/2009 and then became entitled due to age on
7/1/2010. Two MSP Response records will be returned with a ‘01’ disposition code and ‘Y’ in
the Split Entitlement Indicator. The first response record shows an MSP occurrence under the
disability entitlement with an effective date of 1/1/2010 and a termination date of 6/30/2010. The
second shows an MSP occurrence with an effective date of 7/1/2010 and an open-ended
termination date under the aged entitlement. The “split date” is 7/1/2010. If you now send an
update or delete record with the same key fields as you originally sent including the effective
date of 1/1/2010, the system will apply the update or delete to both records. Suppose you send an
update to submit a termination date for the GHP coverage for 9/30/2010. Since the first record is
already terminated prior to 9/30/2010, the 9/30/2010 date would only get applied to the second
record.
However, there is a circumstance where this will not work. It is only when a GHP termination
date is submitted that is PRIOR to the “split date.” The system splits the incoming transaction
first and then applies the split records to MSP occurrences it has or creates MSP occurrences if
applicable. If a record is sent that has a termination date prior to the split date, then it won’t be
split. This results in the update transaction only being applied to the first record. In order for this
to happen in the example above, you would have to submit an update record with an effective
date of 1/1/2010 and a termination date prior to 7/1/2010. That termination date would only be
applied to the first record and the second record would remain open which is not what you want
to happen since the GHP coverage ended. The result would be an open-ended MSP occurrence
7/1/2010 – 00/00/0000. Medicare would erroneously deny claims submitted as primary with
dates of service 7/1/2010 and subsequent until this MSP occurrence is deleted. Even though this
doesn’t occur very often RREs should maintain the split records in their systems in order to
properly maintain the MSP occurrences.
To correctly maintain MSP information and avoid the situation described above, the RRE would
need to take the MSP Effective and MSP Termination Dates returned on the split response
records, maintain those in its system and send updates and deletes using those dates. In other
words, using this example, maintain two separate records one for 1/1/2010 – 6/30/2010 and the
other for 7/1/2010 – 00/00/0000. However, there is no reason to maintain the first MSP
occurrence which was terminated on 6/30/2010 unless you reported it erroneously and it needs to
be deleted or the GHP coverage actually ends prior to 6/30/2010. In that case, an update would
be sent to terminate the first record and a delete would be sent to remove the MSP occurrence of
7/1/2010 – 00/00/0000. For any other coverage changes, just the second record with an MSP
Effective Date of 7/1/2010 will need to be maintained ongoing.

7.2.8.8 End Stage Renal Disease (ESRD)

In order to allow Section 111 reporting entities to better coordinate benefits for Medicare
beneficiaries with End Stage Renal Disease (ESRD), the BCRC will provide ESRD data fields
on your MSP Response File. These fields are the ESRD Coordination Period Start and End
Dates, the First (oldest) Dialysis Date, the Self-Training Date, the most recent Kidney Transplant
Date, and the most recent Kidney Transplant Failure Date. Please refer to MSP Response File
Fields 75-80 in the file specifications in Appendix A.
For an individual with ESRD there is an initial 30-month coordination of benefits period where
the patient’s GHP coverage may be primary to Medicare. Subsequent to that 30-month period,
Medicare becomes the primary payer regardless of the patient’s other GHP coverage. There are

7-51
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

conditions that must be met in order for a patient to receive Medicare benefits and coverage for
an ESRD diagnosis. Refer to https://www.cms.gov/ESRDGeneralInformation/
https://www.cms.gov/OrigMedicarePartABEligEnrol/ and
https://www.cms.gov/Medicare/Coordination-of-Benefits-and-Recovery/Coordination-of-
Benefits-and-Recovery-Overview/End-Stage-Renal-Disease-ESRD/ESRD.html for more
information related to the coordination of benefits with Medicare for ESRD. This topic is also
covered in the computer-based training curriculum made available to RREs as described in
Chapter 13.
Note that the MSP Effective Date on the MSP Response File may be adjusted to coincide with
the start date for the 30-month coordination period in which GHP coverage is considered primary
to Medicare.

7.2.9 MSP Hierarchy Requirements

7.2.9.1 Background
The BCRC is charged with collecting information to identify other health insurance that
Medicare beneficiaries have that is primary to Medicare coverage. This other insurance
information is posted by the BCRC in the form of MSP occurrences on the Medicare Common
Working File (CWF) and Medicare Beneficiary Database (MBD). It is then used in the Medicare
claims payment process to prevent mistaken payment of Medicare benefits and for subsequent
recovery where mistaken payments were made prior to the identification of the other primary
health insurance.
In order to obtain comprehensive other insurance information and post it to CWF in a timely
fashion to prevent mistaken Medicare payments, the BCRC utilizes various methods of data
collection including mandated employer questionnaire responses from the IRS/SSA/CMS Data
Match process, mandated Section 111 reporting, voluntary data sharing agreements, and
telephone calls to the Beneficiary Call Center (1-800-Medicare) and the BCRC Call Center.
While each of these methods has proven effective, CMS has found that historically, some
sources are more reliable than others and collection from different entities can result in
conflicting information or “flip-flopping” of certain fields that make up an MSP occurrence. This
in turn can result in reduced data integrity, inaccurate Medicare claim payment and recovery
issues. Most often, the conflicting information is related to the MSP Termination Date. For
example:
On 10/10/2010, RRE #12345 submits the following MSP Input File Detail Record which
reflects open-ended GHP coverage (the Termination Date is all zeroes):
• Medicare ID (HICN or MBI): 111002222
• Effective Date: 1/1/2011
• Termination Date: 00/00/0000
The BCRC accepts the record and posts the MSP occurrence to CWF. The beneficiary’s
GHP coverage is primary to Medicare as of 1/1/2011.
On 4/10/2011, the Medicare beneficiary (Medicare ID: 111002222) contacts the BCRC
customer service department. The beneficiary reports that he or she retired on 3/1/2011. The
BCRC Customer Service Representative (CSR) verifies this information and applies the
3/1/2011 Termination Date to the MSP occurrence.

7-52
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Note: 3/1/2011 is submitted as the Termination Date because this is the last day that the
Medicare beneficiary is covered through the GHP due to current employment. Medicare
becomes the primary payer as of 3/2/2011.
On 5/1/2011, RRE #12345 submits an update to the previously accepted record to correct the
Individual Policy Number submitted on its original Add Record. This RRE is not aware that
the Termination Date has been updated (i.e., the beneficiary retired).
The RRE submits the following information on their update record.
• Medicare ID 111002222
• Effective Date: 1/1/2011
• Termination Date 00/00/0000 (date submitted on the original Add Record)
• Updated Policy Number
In the past, this update transaction would have automatically been applied and would have
removed the Termination Date that was added by the BCRC CSR. The MSP occurrence would
have been incorrectly reopened. The GHP coverage would have once again been primary to
Medicare. This would have resulted in improper handling of the beneficiary’s Medicare claims.
To address issues like these and improve the integrity of MSP information posted to CWF, CMS
developed Hierarchy Requirements which are used by the BCRC in the maintenance of MSP
occurrences.

7.2.9.2 Hierarchy Requirements

CMS has ranked all of the possible sources of an update/delete request from the highest level
(first) to the lowest level (fifth). When an update or delete transaction is received that matches an
existing MSP occurrence, the source of that information and its associated hierarchy ranking will
be compared to the source and hierarchy ranking of the existing occurrence. Table 7-6 illustrates
the hierarchy rank associated to each source. When an update/delete transaction is received, the
BCRC will compare the source of the incoming transaction to the source of the existing
transaction. The decision to apply the update or delete will be based on the hierarchy ranking of
each source. If the hierarchy ranking of the source on the incoming transaction is greater than or
equal to the hierarchy ranking of the source on the existing transaction, the update/delete
transaction will be allowed. If the hierarchy ranking of the source on the incoming transaction is
lower than the hierarchy ranking of the source on the existing transaction, the update/delete
transaction will NOT be allowed.

Table 7-6: Hierarchy Requirements

Hierarchy Ranking Source of Update/Delete Request
First BCRC Analyst (Note: the BCRC Analyst will have the authority to manually
lock an MSP occurrence from any subsequent changes except those made by
the BCRC).
Second • BCRC Call Center
• BCRC CSR
• Commercial Repayment Center (CRC)
• Beneficiary Call Center (1-800-Medicare)
Third • Section 111 RRE
• Medicare Advantage (MA) / (Part C Plan)

7-53
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Hierarchy Ranking Source of Update/Delete Request

Fourth • Employer Voluntary Data Sharing Agreements (VDSAs)
• Employer response to IRS/SSA/CMS Data Match Questionnaire
Fifth • Other Medicare Contractors
• All others

7.2.9.3 Processing Records using Hierarchy Requirements

Using the Hierarchy Requirements, when an update or delete transaction is received, the BCRC
will:
• Attempt to match the incoming update or delete transaction to an existing MSP
occurrence.
• Reject the record, if there is no match.
• If there is a match, it will compare the hierarchy ranking of the entity submitting the
current (incoming) transaction to the hierarchy ranking of the entity that last added,
updated, or deleted the matching MSP occurrence.
• Apply the following rules to the existing MSP occurrence:
• Allow the update/delete if the hierarchy ranking of the source of the request is greater
or equal to the hierarchy ranking of the entity that last added or changed the
occurrence.
• Disallow the update/delete if the hierarchy ranking of the source of the request is
lower than the hierarchy ranking of the entity that last added or changed the
occurrence. (These update/delete transactions will be rejected).
The examples that follow (also depicted in Table 7-7) demonstrate how an update/delete
transaction will be handled by the BCRC:
1. If the current source of an update/delete transaction (e.g., a BCRC CSR or the CRC in Tier 2)
is a higher ranking source than the previous source of the add/update/delete (e.g., an RRE in
Tier 3), the update/delete will be allowed.
2. If the current source of an update/delete transaction (e.g., a Medicare Advantage Plan in Tier
3) is in the same ranking Tier as the previous source of the add/update/delete (e.g., an RRE in
Tier 3), the update/delete will be allowed.
3. If the current source of update/delete transaction (e.g., an RRE in Tier 3) is in a lower
ranking Tier than the previous source of the add/update/delete (e.g., a BCRC CSR or the
CRC in Tier 2), the update/delete will NOT be allowed.

Table 7-7: Hierarchy Requirements Examples

Current Source (Tier Level) of Previous Source (Tier Level) of Change
Update/Delete Transaction Add/Update/Delete Transaction Permissible
BCRC CSR or CRC (Tier 2) Section 111 GHP RRE (Tier 3) Yes
Medicare Advantage Plan/Part C Plan Section 111 GHP RRE (Tier 3) Yes
(Tier 3)
Section 111 GHP RRE (Tier 3) BCRC CSR or CRC (Tier 2) No

7-54
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

7.2.9.4 Effect of Hierarchy Requirements on RRE submissions

Even with MSP hierarchy requirements in place, MSP occurrences established by RREs can be
updated or deleted by other RREs, the BCRC Call Center, a BCRC Analyst, the Beneficiary Call
Center (i.e., 1-800-633-4227), or a Medicare Advantage (MA) Plan.
Figure 7-1 shows which entities can/cannot change an MSP occurrence that was last added,
updated, or deleted by an RRE.

Figure 7-1: MSP Occurrence Add, Update, and Delete Permissions

The MSP hierarchy requirements also affect the RREs ability to make updates or deletes to
records. Figure 7-2 shows the precedence of an update or delete transaction submitted by an RRE
to a previously submitted record.

7-55
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Figure 7-2: MSP Occurrence Update & Delete Permissions

When an RRE attempts to update or delete an MSP occurrence that was last added or updated by
a higher-ranking source, the record will be rejected. The error returned on the MSP Response
File will depend on whether or not the MSP occurrence is locked. As noted in Table 7-6 , the
BCRC Analyst will have the authority to manually lock an MSP occurrence from any
subsequent changes except those made by the BCRC. Records rejected due to hierarchy
requirements will include the following errors:
SPH0 (ending in the numeral zero) – Transaction attempted to update/delete an MSP
occurrence last updated by a higher-ranking source. MSP occurrence is not locked.
SPH1 – Transaction attempted to update/delete an MSP occurrence locked by the BCRC. No
update or delete accepted via Section 111 reporting.

7.2.9.5 Hierarchy Override Code

The Override Code, Field 33, on the MSP Input File Detail Record, allows an RRE (Third Tier)
to apply an update or delete to an unlocked MSP occurrence that was last updated by a
source/entity ranked higher than the RRE in terms of the MSP hierarchy requirements. Please see
Section 7.2.10.8 for additional information.
• After receipt of the SPH0 error, you must:
• Review submitted information and determine if the update/delete must be applied:
• If you determine that the update/delete must be applied, then submit the transaction
again in your next quarterly file submission with a value of HB (Hierarchy Bypass) in
the Override Code (Field 33) of the MSP Input File Detail Record.
• If you determine that the update/delete does not need to be applied, which may be the
case if your information is out of date (e.g., the employee/subscriber retired), then
update the information in your internal system and take no further action.
• After receipt of the SPH1 error:

7-56
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

• You are advised to contact the associated employer/other plan sponsor to verify the
accuracy of the submitted data.
• Do NOT attempt to resubmit this record. The only way to apply the update/delete is
by contacting the BCRC.
• If changes are necessary, contact the BCRC Monday through Friday, from 8:00 a.m.
to 8:00 p.m., Eastern Time, except holidays, at toll-free lines: 1-855-798-2627 or
TTY/TDD: 1-855-797-2627 for the hearing and speech impaired.
• If you determine that the update/delete does not need to be applied, then update the
information in your internal system and take no further action.
Note: You are advised to retain a record of SPH0 and SPH1 errors received as documentation of
failed Section 111 data submission attempts.

7.2.10 Unsolicited Response File

7.2.10.1 Overview
The Unsolicited MSP Response File was implemented to notify GHP RREs whenever another
entity changes or deletes an MSP occurrence previously submitted by them. GHP RREs can
voluntarily elect to participate and receive this file. Once an RRE elects to receive the
Unsolicited MSP Response File, the BCRC will track the MSP occurrences for which the RRE
has submitted MSP Input File records that were accepted with a ‘01’ disposition code. Whenever
one of these MSP occurrences is changed by a source other than the participating RRE, a record
is written to the RRE’s Unsolicited MSP Response File. The BCRC then transmits the
Unsolicited MSP Response File to the RRE once per month. The Unsolicited MSP Response File
contains information for the RRE to identify the MSP occurrence and information regarding the
modifications that were subsequently applied (e.g., source and reason for the change).

7.2.10.2 Benefits
This prompt notification of changes and identification of the source of changes will assist
participating RREs in many ways:
• By electing to use and verify the information in the Unsolicited MSP Response File, a
participating RRE can submit an update transaction on their MSP Input File using the
Hierarchy Override Code (HB) before receiving the SPH0 error. (Please see the Section
7.2.10.8 for more information). Note: An SPH0 error will be received if an RRE submits
an update/delete transaction for an MSP occurrence that was last updated by a higher-
ranking source.
• Allow for more precise confirmation or investigation of GHP coverage and its relevance
to MSP determinations. Knowing the source of the change and reason for the
update/delete request will assist the RRE in confirming the validity of a reported
modification, and of the data in its own system The RRE can use this information to
verify the accuracy of the update/delete request with the source that submitted the change
to ensure compliance with Section 111 reporting.
• Provide information that may be useful in the RRE’s business relationships with their
employer/other plan sponsor customers to help rectify discrepancies.
• Improve both the accuracy of data reporting and its compliance with the Section 111
reporting requirements. Once verified, the RRE can use this information to update their

7-57
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

internal systems if their data is incorrect or submit an override record if their data is
correct.
• Improve the overall accuracy of MSP information used and stored by Medicare, RREs,
and employers.

7.2.10.3 RRE Enrollment and Termination

Enrollment
RRE’s electing to receive Unsolicited MSP Response Files must sign up for this process on the
Section 111 COBSW at https://www.cob.cms.hhs.gov/Section111/.
New RREs: Newly registering RREs that would like to receive the Unsolicited MSP
Response File will select this option during the registration process on the Section 111
COBSW. During Account Setup, the Account Manager must select “Yes” for the “Would
you like to receive Unsolicited Alerts” question on the Company Information page.
Existing RREs: If the RRE has already completed their registration for Section 111, the
Account Manager must login to the Section 111 COBSW and select the “RRE Information”
action on the RRE Listing page. The Account Manager must then edit the RRE’s information
and change the “Receive Unsolicited Alerts” option to “Yes”.
Please see the Section 111 COBSW User Guide for more detailed information on the RRE
Listing page. Your EDI Representative can also provide assistance as needed.
Termination
To discontinue receiving the Unsolicited MSP Response File, the Account Manager must again
login to the Section 111 COBSW and change the “Receive Unsolicited Alerts” option to “No”
using the “RRE Information” action. Once an RRE opts out of this process, they will no longer
receive the Unsolicited MSP Response File. Partial files will not be created (i.e., if an RRE
discontinues this process prior to the monthly Unsolicited MSP Response File generation, they
will not receive any file that month).

7.2.10.4 Interested Party Table

Once an RRE has elected to receive the Unsolicited MSP Response File, the participating RRE is
identified as an “Interested Party” (i.e., the RRE ID now has an “interest” in receiving alerts
when MSP occurrences submitted by them are changed by another entity).
For those RREs that have elected to receive the Unsolicited MSP Response File, the BCRC will
create and maintain entries in what is referred to as the “Interested Party table”. The Interested
Party table will contain information related to the MSP occurrences for which a participating
RRE might be interested in receiving notifications.
The initial Interested Party table entries will be created by the BCRC on the first Sunday after the
RRE’s Account Manager has enrolled in this process. The BCRC will search through the last 12
months of MSP Response Files that were transmitted back to the participating RRE. It will
identify all new or changed MSP occurrences that received a ‘01’ disposition code. For each,
most recent, unique, MSP occurrence identified, the BCRC will create a record in the Interested
Party table. These records indicate which MSP occurrences the participating RRE has an interest
in.

7-58
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

The BCRC will then continue to maintain entries in this table for the RRE. Whenever the
participating RRE submits an add, update or delete transaction that receives a ‘01’ disposition
code, the Interested Party Table will be updated accordingly:
• Update Records will be applied as updates to the Interested Party table. The most recent
Document Control Number (DCN) submitted by the participating RRE will be stored on
the Interested Party table so that it can be returned on Unsolicited MSP Response File
Detail Records.
• Delete Records will remove the entries from the Interested Party table. It is assumed that
once the record is deleted by the participating RRE, they no longer have an interest in the
record. The BCRC will not produce any subsequent Unsolicited MSP Response Records
for deleted records.
• Add Records will be added to the Interested Party table as new occurrences the RRE is
interested in.
Whenever one of these MSP occurrences is changed (or deleted) by a source other than the
participating RRE, a record is written to the RRE’s Unsolicited MSP Response File.

7.2.10.5 File Creation and Transmission

The Unsolicited MSP Response File includes a Header Record designated by a value of “USOL”
in Field 3, followed by Detail Records for each notification, followed by a Trailer Record. The
Trailer Record contains a count of the total number of notification records included in the
submission. This count does not include the Header and Trailer Records. Note: The Unsolicited
MSP Response File layout is documented in
Appendix H.
If no Unsolicited MSP Response File Records (notifications) are created for an RRE during the
course of a month for a participating RRE, an “empty” Unsolicited MSP Response File will be
transmitted to the RRE. This file will include a Header Record, no Detail Records and a Trailer
Record with a value of all zeros in the File Record Count (Field 5).
Unsolicited MSP Response Files are created and transmitted to participating Section 111 GHP
RREs on a monthly basis on the second Sunday of each month. RREs must have signed up on
the Section 111 COBSW at least 9 days in advance of the file creation date in order to receive an
Unsolicited MSP Response File for that month. If an RRE does not enroll in the process at least
9 days prior to the second Sunday of the month, the RRE’s file transmission will commence the
following month. This file will NOT be created for test file transmissions.
Unsolicited MSP Response Files will be transmitted the same way MSP Response Files are sent
to the participating RRE. For example, if the MSP Response Files are delivered via Secure File
Transfer Protocol (SFTP), the Unsolicited MSP Response Files will be transmitted via SFTP.
Connect:Direct - RREs using the Connect:Direct file transmission method must contact their
EDI Representative to set up the necessary parameters including the destination dataset name
to be used by the BCRC. Without this information, transmission of the Unsolicited MSP
Response File will fail.
SFTP - For RREs using SFTP, the Unsolicited MSP Response File will be placed in the same
mailbox that the MSP Response File is delivered: /RREID/response/prod/msp.

7-59
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

HTTPS - For RREs using Hypertext Transfer Protocol over Secure Socket Layer (HTTPS),
the Unsolicited MSP Response File will be available for download from the RRE’s Section
111 COBSW File Listing page.
Note: For SFTP & HTTPS submitters, the BCRC will name Unsolicited MSP Response Files
according to the following convention
PCOB.BA.MR.GHPUNS.RESP.Dccyymmdd.Thhmmsscc.TXTwhere‘Dccyymmdd’ is ‘D’
followed by a date as century/year/month/day and ‘Thhmmsscc’ is ‘T’ followed by a time as
hours/minutes/seconds/centiseconds. The date and timestamp used in the response file names
are generated by the BCRC when it creates the response file.

7.2.10.6 Unsolicited MSP Response File Records

Unsolicited Response File Records reflect changes (updates and deletes) made to MSP
occurrences listed in the participating RRE’s Interested Party Table that were submitted by an
entity other than the RRE during the course of the last month. Note: If more than one change is
made by another entity to a particular MSP occurrence during a month, only one Unsolicited
MSP Response Detail Record will be created reflecting the most recent change applied.
Unsolicited Response File Records include:
• Key matching fields for the MSP occurrence (including the last DCN submitted by the
participating RRE);
• Current values for other fields associated with the MSP occurrence (i.e., if an MSP
occurrence was updated multiple times during the monthly timeframe, only information
from the last change made will be sent); and,
• Most recent Medicare beneficiary entitlement and enrollment information (although
changes to this information will not cause an Unsolicited MSP Response Record to be
created).
Unsolicited Response File Records are limited to changes made to MSP occurrences reflecting
hospital and medical coverage (i.e., changes applied exclusively to prescription drug coverage
MSP occurrences will not cause an Unsolicited MSP Response Record to be created).
Some particular fields of interest on the Unsolicited MSP Response File include the following:
• Field 9 (Last Transaction Type) will identify the last action performed on the MSP
occurrence by an entity other than the participating RRE. A value of ‘0’ means the other
entity updated the MSP occurrence. A value of ‘1’ means the other entity deleted the
MSP occurrence.
• Fields 10-32 will contain the current MSP information for the occurrence.
• Field 33 (Modifier Type) & Field 34 (Modifier Name) will contain information related to
the updating source. Field 33 will indicate the type of entity that applied the modification
to the MSP occurrence. Field 34 will identify the name of the source of the modification
(if available). Please see Table 7-8 for a complete list of the valid values.
• Field 35 (Change Reason Code) will indicate why the occurrence was modified (if
known). If a reason for change cannot be determined the value of ‘UK’ (Unknown) or
blank will be returned. See for a complete list of the valid values.
• Field 36 (Last Update Applied Date). This field will identify the date the BCRC last
changed the occurrence.

7-60
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Table 7-8: Modifier Type Code and Modifier Name

Modifier Type Value in Modifier Name if Description
Code (Field 33) available (Field 34)
CBN Beneficiary Name Change made by a BCRC
CSR/Analyst due to information
received from a Medicare beneficiary
CEM Employer/Other Plan Sponsor Name Change made by a BCRC
CSR/Analyst due to information
received from an employer or other
plan sponsor
CIN Insurer Name Change made by a BCRC
CSR/Analyst due to information
received outside the Section 111
reporting process from an insurer or
TPA
ECR Contractor number 11139, 11141, Change was made due to information
11142 or 11143, received from another Medicare
If the change was made due to Group contractor
Health Plan Recovery, the Modifier
Name will contain the value 11139.
If the change was made due to Non-
Group Health Plan Non-ORM
Recovery, the Modifier Name will
contain the value 11141.
If the change was made due to Non-
Group Health Plan ORM Recovery,
the Modifier Name will contain the
value 11142.
If the change was made due to a Part
C/Medicare Advantage Plan request,
the Modifier Name will contain the
value 11143.
RRE Name of the RRE Systematic change applied due to a
transaction submitted by an RRE
other than the participating RRE
COB BCRC Other change made by the BCRC
DSA* Name of the Voluntary Data Sharing Systematic change applied by the
Agreement (VDSA) entity BCRC employer/other plan sponsor
VDSA process
DTM* Name of employer submitting the Systematic change applied by the
Data Match Questionnaire Response BCRC employer IRS/SSA/CMS
Data Match Questionnaire response
process
800 1-800-MEDICARE Change made by a 1-800-
MEDICARE CSR due to
information received from a
Medicare beneficiary.
Note: Due to MSP hierarchy rules applied by the BCRC when applying updates and deletes to
MSP occurrences, these Modifier Type values will not be returned to Section 111 RREs on
Unsolicited MSP Response Files.

7-61
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Table 7-9: Change Reason Description

Change Reason (Field 35) Description
ES Employer size change
CE Change in employment status
UK Unknown
II Insurance information change
EI Employer information change
EC Entitlement change
Blank System generated, reason unknown

7.2.10.7 Using the Unsolicited MSP Response File

The Unsolicited MSP Response File provides notification to an RRE in regard to changes or
deletes made by another entity to MSP occurrences previously submitted by them. Although
RREs are not required to develop processing to react to the Unsolicited MSP Response File,
RREs should use the information it provides to investigate the coverage information further,
work with beneficiaries and employers to rectify discrepancies, and update their internal systems
as deemed appropriate.
If the RRE confirms that a change made by another entity was accurate, the RRE should apply
the changed information, such as retirement or employment termination dates, to its internal
system and use this information as applicable for subsequent Section 111 reporting and claim
processing. However, if the RRE determines that a change made by another entity was
inaccurate, they must take steps to correct the error on their next MSP Input File or follow up
with the BCRC Call Center as appropriate. By effectively using the Unsolicited MSP Response
File to maintain accurate records, the RRE can help avoid the risk of non-compliance with
Section 111 reporting requirements.

7.2.10.8 Hierarchy Override Code Usage

RREs Participating in the Unsolicited MSP Response File
RREs that participate in the Unsolicited MSP Response File process do not need to wait to
receive an SPH0 error on an MSP Input File Detail Record before being able to submit the HB
Override Code (Section 7.2.9.5) RREs may submit the Override Code on a MSP Input File
Detail Record after receipt of an Unsolicited MSP Response File Record. By opting to use the
Unsolicited MSP Response File, an RRE can streamline the hierarchy override process and apply
the necessary change in one quarterly MSP Input File submission.
Please note that RREs should NOT automatically attempt to override any records without
first validating that their information is correct.
Override Code example
An RRE participating in the Unsolicited MSP Response File process submitted an MSP Input
File Add Record for GHP coverage provided to a Medicare beneficiary. The record was accepted
by the BCRC and the RRE received a ‘01’ disposition code on its response file indicating that an
MSP occurrence was created. This record was added to the RRE’s Interested Party Table
(Section 7.2.10.4). Subsequently, the beneficiary called the BCRC Call Center and stated that he
or she did not have the GHP coverage reflected in the MSP occurrence. In this case, the MSP

7-62
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

occurrence had to be deleted since Medicare should be the primary payer. A BCRC CSR
manually deleted the MSP occurrence and applied the Modifier Type Code of ‘CBN’ (Change
made by a BCRC CSR/Analyst due to information received from a Medicare beneficiary).
Since the change (i.e., the delete) to this occurrence was made by an entity other than the
participating RRE (change was made by the BCRC CSR), a notification for this deletion was
sent to the participating RRE on their next Unsolicited MSP Response File. When the RRE
received their Unsolicited MSP Response File, they researched this situation, contacted the
beneficiary and were able to confirm that this deletion was incorrect. Since the change (deletion)
was made by a BCRC CSR which is ranked higher than the RRE in the MSP hierarchy
requirements, the RRE will need to override the CSR’s change in order to add this record back.
Since the RRE received an Unsolicited MSP Response notification, it may utilize the override
code without first getting the SPH0 error.
RREs Not Participating in the Unsolicited MSP Response File
Non-participating RREs can only submit the Override Code in their next quarterly submission if
they:
• First receive the SPH0 error, and
• Verify that the override is appropriate and necessary.
RREs not participating in the Unsolicited MSP Response program cannot use the Override Code
(Section 7.2.9.5) until they first receive an SPH0 error (i.e., attempt to update/delete an MSP
occurrence last updated by a higher ranking source) on an MSP Input File Detail Record. If the
Override Code is submitted on an MSP Input File Detail Record without first receiving the SPH0
error, the SPH2 error (transaction attempted to override the SPH0 error without prior
notification) will be returned.
RREs not participating in the Unsolicited MSP Response program may have to potentially
submit two quarterly MSP Input Files (taking approximately six months to apply their change) if
their first attempt to submit an update or delete rejects with an SPH0 error. The first submission
would be when they attempted to update/delete an MSP occurrence, but the record rejected with
an SPH0. The second submission would be on their next quarterly MSP Input File using the
Override Code for the record previously rejected with the SPH0 error.
Note: This process could actually take longer than two submissions, or more than six months to
rectify, depending on the length of time needed to verify the change.
Since RREs are ultimately responsible for ensuring that their MSP records are submitted with
accurate information, they should take advantage of and enroll in the Unsolicited MSP Response
File process.

7.3 Query Only Input File Requirements

7.3.1 Overview
The Query Only Input File is a dataset transmitted from a GHP Section 111 responsible reporting
entity under the Basic and Expanded Reporting Options to request information regarding
Medicare status and Medicare Part A entitlement and Parts B and C enrollment of individuals
covered by the GHP. Note that this file does not currently provide Medicare Part D enrollment
information. You may submit query records for any individual covered by your GHP.

7-63
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

If you are using the “finder file” approach for reporting individuals on your MSP Input File, you
may use the results of the query process to determine which Active Covered Individuals are
Medicare beneficiaries and must be reported on the MSP Input File. In addition, you may use the
Medicare coverage dates in your GHP claims processing system when determining whether to
pay primary or secondary to Medicare. In most cases for Inactive Covered Individuals, if the
individual is a Medicare beneficiary, then Medicare will be the primary payer.
Query Only Input File records must be submitted with the Medicare ID (HICN or MBI) or SSN,
name, date of birth and gender of the covered individual. The query process is to be used only for
Section 111 reporting purposes. Please review the Data Use Agreement in Chapter 10 of this
guide for restrictions on the use of data exchanged for Section 111.
To determine whether a submitted covered individual is a Medicare beneficiary, the BCRC must
match your data to Medicare’s. This matching can be done using either an individual’s Medicare
ID or by using an individual’s SSN. For matching an individual to determine if they are a
Medicare beneficiary the BCRC uses:
• Medicare ID or SSN
• First initial of the first name
• First 6 characters of the last name
• Date of birth (DOB)
• Gender
First the BCRC must find an exact match on the Medicare ID or SSN. Then at least three out of
the four remaining criteria must be matched exactly. If a match is found, you will always be
returned the current Medicare ID for the individual on the corresponding response record. You
must store this Medicare ID on your internal files and use it on future transactions. This is CMS’
official identifier for the beneficiary. The BCRC will also supply updated values for the first
initial, first 6 characters of the last name, date of birth and gender in the applicable fields of the
Query Only Response File records based on the information stored for that beneficiary on
Medicare’s files. The SSN returned on the response record will always be the SSN submitted on
the query input record by the RRE. Other than the Medicare ID, the updated fields returned on
the response record are simply for informational purposes.
Note that if an RRE submits a value of ‘0’ for an unknown gender for an individual, the BCRC
will change this value to a ‘1’ for matching purposes and return that changed value of ‘1’ on the
response record regardless of a match.
Also note that if an RRE submits both the SSN and Medicare ID on a query record, the system
will only use the Medicare ID for matching purposes and the SSN will be ignored. The system
will attempt to match the Medicare ID to any previously assigned Medicare ID for the individual,
since Medicare IDs can change or be reassigned by SSA, but if no match is found using the
Medicare ID it will not then attempt to match using the SSN provided.
After the BCRC has processed the Query Only Input File it will return the Query Only Response
File with a determination as to whether the queried individual can be identified as a Medicare
beneficiary based upon the information submitted. The Query Only Response File records
contain a Disposition Code. A value of ‘01’ indicates that the individual submitted on the input
record is/was a Medicare beneficiary and the record will contain the updated Medicare ID, name
fields, DOB and gender according to Medicare’s information along with Medicare entitlement
and enrollment dates. The BCRC will never return an updated or corrected SSN on the Query
Only Response File. You must store the Medicare ID returned on the query response in your
7-64
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

internal system and are required to use it on future transactions. A value of ‘51’ indicates that the
information supplied on the query record could not be matched to a Medicare beneficiary.
The Query Only Files must be transmitted in the HIPAA-compliant ANSI X12 270/271
transaction set. You may use your own translator software, or the HIPAA Eligibility Wrapper
(HEW) software (provided by the BCRC) to submit a Query Only Input File and process the
Query Only Response File. To use the HEW software, you first will create an input file
according to the specifications in Appendix B. This flat file is then used as input to the HEW
software. You will install and run the HEW software at your processing site. The HEW software
produces the X12 270 eligibility query file format which you then transmit to the BCRC. The
BCRC will send back your response file in the X12 271. You will feed that into the HEW
software to produce the Query Only Response File according to the specifications in Appendix
B. This flat file containing Medicare entitlement and enrollment information for the individuals
found to be Medicare beneficiaries can then be used in your internal systems to determine which
individuals must be reported on the MSP Input File and to assist with coordination of benefits in
your claims processing. Note that the Query Only Response File that is output from the HEW
software does not contain any header or trailer records.
Mainframe and Windows PC/Server-based versions of the HEW software are available. You
may download the Windows version of the HEW software after logging on to the Section 111
COBSW at https://www.cob.cms.hhs.gov/Section111/. You may request a copy of both the
mainframe and Windows versions from your EDI Representative or by contacting the EDI
Department at 646-458-6740.
Query Only Input and Response File specifications for the flat files that are the input and output
of the HEW software can be found in Appendix B.
If you choose to use your own ANSI X12 translator to create the ANSI X12 270 files for the
Section 111 Query Only File and process the X12 271 response, download the 270/271 Health
Care Eligibility Benefit Inquiry and Response Companion Guide for Mandatory Reporting GHP
Entities document at the bottom of the cms.gov web site. This document includes the X12
270/271 mapping required for Section 111.

7.3.2 Query Only Input File Detailed Requirements

• Query Only Files must be transmitted in the HIPAA-compliant ANSI X12 270/271
transaction set.
• Query Only Input Files may be submitted up to once per calendar quarter. Calendar
quarters are defined as January – March, April – June, July – September, and October –
December for the Query Only File submissions. For example, a Query Only Input File
may be submitted in March and again in April of the same year since March is in the first
calendar quarter and April in the second. However, if a Query Only Input File is
submitted in April, another file cannot be submitted in June of the same year, since April
and June are both in the second calendar quarter. These files do not have to be submitted
during a specific submission timeframe, or on a specific day, but cannot exceed the
allowed frequency.
• Only Medicare Part A, Part B and Part C coverage information will be supplied on the
Query Only Response File.
• Query Only Response Files will be returned to you within 14 days.

7-65
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

• The following edits will be applied to the Query Only Input File. Any failure of these
edits will result in the file being placed in a severe error status. You will receive an email
notification and are to contact your EDI Representative to address the identified errors.
Files failing for these errors must be corrected before they can be processed.
• File does not contain a header record
• Header record does not contain a valid Section 111 RRE ID
• File does not contain a trailer record.
• Email notifications will be sent to the Account Manager for the RRE ID after the file has
been received and when a response file has been transmitted or is available for download.
• The HEW Query Only Response Files have NO header and trailer records.
• Two RRE-defined, optional document control number (DCN) fields are available for use
on the X12 270/271 and the latest version of the HEW Query Only Input/Response Files.
The DCN fields are alphanumeric, may contain spaces, numbers, letters, and special
characters as defined for a text field type, are left justified and unused bytes must be
space-filled. The BCRC will always return query response records with whatever value
the RRE submitted in these DCNs so that the RRE may use them to match response
records to input records.

7.3.3 HEW Software Processing Environment Requirements

The HEW software is available in mainframe and Windows PC/Server versions. It will not run
on an AS400, Linux or UNIX platform. Network communication ports are not part of the HEW
application. The HEW only converts incoming files. Telecommunications must be done
separately.
The Windows PC/Server version will execute on any Microsoft operating system of NT or better
(2000, 2003, XP, etc.) and requires at least a Pentium II with 64 MB of memory. APIs
(application program interfaces) are not made available for the Windows version. However,
effective with Version 2.0.0 released in January 2010, the Windows PC/Server version of the
HEW may be invoked using a command line interface. Instructions on how to invoke the HEW
software from an automated process can be found in documentation that is contained in the
software package download.

7.3.4 Query Files and HEW Software Requirements

The BCRC will only accept test and production query files submitted using Version 5010A1
(and the latest HEW software version) of the ASC X12 270/271.
• A copy of the latest PC/server HEW software is available for download on the Section
111 COBSW at https://www.cob.cms.hhs.gov/Section111/. (Note: You must log into the
application to download.)
• RREs using the mainframe version of the HEW may request a copy of the latest HEW
version from their EDI Representative.
• Query files submitted under Version 4010A1 (or created using HEW Versions 1.2.0 and
2.0.0) will be rejected with a severe error and not processed.

7-66
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

7.4 Non-MSP Input File Requirements

7.4.1 Overview
This is the data set transmitted from a GHP Responsible Reporting Entity (RRE) under the
Expanded Reporting Option to the BCRC that is used to report information regarding the
prescription drug insurance coverage information of your Inactive Covered Individuals. These
are people who are not currently employed by the GHP Plan Sponsor (most are carried as
retired), a spouse, and other dependents, that are enrolled in a GHP but cannot be classified as
Active Covered Individuals. The Non-MSP Input File is used to report drug coverage
information that is secondary or supplemental to Medicare Part D. Information related to End
Stage Renal Disease (ESRD) is also provided back on the Non-MSP Response File. You may
use this information in your claims processing to determine the primary payer. In most cases for
Inactive Covered Individuals, if the individual is a Medicare beneficiary, then Medicare will be
the primary payer. The Non-MSP Input File can also be used to query CMS about potential
beneficiary Medicare Parts A, B, C and D coverage. Finally, this file may also be used as a way
to submit retiree files to the Retiree Drug Subsidy (RDS) Center on behalf of Plan Sponsors
claiming the Retiree Drug Subsidy.
CMS uses the information in the Non-MSP File to determine GHP coverage that is secondary to
Medicare Part D for Medicare beneficiaries, which is then used for proper claims payment and
the calculation of the beneficiary’s True Out of Pocket (TrOOP) drug costs. If the individual
reported is a Medicare beneficiary enrolled in Part D and it is determined that your prescription
drug coverage is secondary or supplemental to Medicare Part D, the BCRC sets up a
supplemental Part D record on the Medicare Beneficiary Database (MBD). Part D supplemental
records have start and end dates based on the later of the beneficiary’s enrollment in Part D and
your coverage start date. A supplemental Part D record will have an open-ended date if both your
coverage and Medicare coverage are active. An end date is applied when either your or
Medicare’s coverage ends.
This file format requires you to initially send an “add” record for the initial report on
supplemental prescription drug coverage for an Inactive Covered Individual or an RDS retiree
file record. If that record is accepted by the BCRC then you only need to apply any changes to
that information in “update” or “delete” records going forward. If the record is not accepted due
to errors, you must correct it and resend. If the record is not accepted due to the individual not
being a Medicare beneficiary or not being enrolled in Part D during the reported drug coverage
period, then you must continue to send it as an add record on all subsequent submissions until the
record is either accepted or your coverage is terminated.
A Non-MSP Response File will be transmitted from the BCRC back to you after the information
supplied in your Non-MSP Input File has been processed. It consists of the same data elements
in the Non-MSP Input File, with updates applied by the BCRC based on Medicare’s information,
disposition and edit codes which let you know what we did with the record, as well as applicable
Medicare entitlement and enrollment information.
This Non-MSP Response File format is also used to send you unsolicited response files
originating from the RDS Center if you are opting to report RDS retiree files through Section
111 reporting. These transmissions from the RDS Center will notify you that significant data you
previously submitted has changed. Unsolicited RDS responses are designated by the “RDSU”
file type in Field 3 in the header and are discussed in a later section of this guide.

7-67
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Non-MSP Input and Response File and data field specifications can be found in Appendix C.
Each field description includes an explanation on how to use the field for the different record
(action) types.

7.4.2 Action Types

Each record on the Non-MSP Input File contains an Action Type in Field 20 to indicate what the
record represents.

7.4.2.1 N – Query Records

Action Type “N” is known as a Non-Reporting Record and is used to query Medicare
entitlement and enrollment information. The corresponding record in the Non-MSP Response
File will contain the Medicare entitlement and enrollment information requested for the
individual. N records may be submitted for any covered individual. They are not limited to
Inactive Covered Individuals.

7.4.2.2 D – Supplemental Prescription Drug Coverage Records

Action Type “D” is known as a Drug Reporting Record and is used to submit prescription drug
coverage that is secondary or supplemental to Medicare Part D for Inactive Covered Individuals.
The corresponding record in the Non-MSP Response File will contain the Medicare entitlement
and enrollment information requested for the individual as well as information about whether the
supplemental drug record was accepted and posted by the BCRC on the MBD.

7.4.2.3 S – RDS Retiree File Records

Action Type “S” is known as a Subsidy Reporting Record and is used to submit retiree file
information to the RDS Center. The corresponding record in the Non-MSP Response File will
contain information from the RDS Center indicating whether the retiree was accepted for the
subsidy program as well as Medicare entitlement and enrollment information for the individual.
Note: If you are not submitting retiree file information to the RDS Center on behalf of a Plan
Sponsor participating in the Part D Retiree Drug Subsidy Program, then you may disregard any
further information regarding S records.

7.4.3 Record Matching Criteria

7.4.3.1 Individuals
To determine whether an individual is a Medicare beneficiary, the BCRC must match your data
to Medicare’s. This matching can be done using either an individual’s Medicare ID (HICN or
MBI) or by using an individual’s SSN. The Medicare ID is preferred. You must send either a
Medicare ID or an SSN as part of the individual’s record in the Non-MSP Input File. For
matching an individual to determine if they are Medicare beneficiary the BCRC uses:
• Medicare ID or SSN
• First initial of the first name
• First 6 characters of the last name
• Date of birth (DOB)
• Gender (Sex)

7-68
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

First the BCRC must find an exact match on the Medicare ID or SSN. Then at least three out of
the four remaining criteria must be matched exactly. If a match is found, you will always be
returned the beneficiary’s most current Medicare ID (HICN or MBI) to use going forward on all
update and delete transactions. You must store the Medicare ID returned on the Non-MSP
Response file in your internal system and are required to use it on future transactions.
Note that if an RRE submits both the SSN and Medicare ID on a Non-MSP Input File Detail
Record, the system will only use the Medicare ID for matching purposes and the SSN will be
ignored. The system will attempt to match the Medicare ID to any previously assigned Medicare
ID for the individual, since Medicare IDs can change or be reassigned by SSA, but if no match is
found using the Medicare ID it will not then attempt to match using the SSN provided.

7.4.3.2 Supplemental Prescription Drug Records

Supplemental drug coverage records created and stored by the BCRC for Medicare claims
processing are keyed by:
• Medicare ID (HICN or MBI)
• Supplemental Coverage Effective Date
• Coverage Type (network drug only, comprehensive hospital/medical/drug, etc.)
• Patient Relationship Code (self, spouse, dependent, etc.) and
• Section 111 RRE ID
The BCRC will use this criterion for subsequent update and delete transactions you send. You
are required to send the Medicare ID that the BCRC sends back to you on the response file on all
subsequent update and delete transactions.

7.4.4 Initial Non-MSP Input File Submission

To begin Non-MSP reporting of supplemental drug coverage for Section 111, you must create
and send a file of D records that contains information for all Inactive Covered Individuals who
are currently enrolled in your plan. Information must be supplied for individuals who had open
coverage at that time even if it has since been terminated. Information must be supplied for
individuals even if their coverage has since been terminated. Information must also be supplied
for individuals who are currently enrolled at the time of the report.
One D record is to be supplied for each individual who qualifies as an Inactive Covered
Individual including the subscriber, the subscriber’s spouse, and every other dependent that fits
the definition of an Inactive Covered Individual. If an individual had multiple periods of
coverage during this timeframe, multiple records must be submitted with the applicable effective
and termination (end) dates (Fields 10 and 11). The effective date should reflect when the
coverage was initially effective even if that occurred prior to January 1, 2009. If the coverage is
current and open at the time of the report, the record should reflect an open-ended coverage by
putting zeroes in the Termination Date (Field 11). Termination dates should only be sent when
the actual coverage reported has ended. Yearly renewals of the same coverage are not to be
reported as separate records. If the coverage remains the same from year to year, a new
record does not need to be reported since the previous report should have had an open-
ended termination date.
Your initial Non-MSP Input File will obviously be larger than your subsequent update files since
it will contain D records for the entire population of your Inactive Covered Individuals for whom

7-69
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

you must report. All records on your initial file will be “add” records and have a value of zero
(‘0’) in the Transaction Type (Field 21).
Your initial Non-MSP Input File may contain N query records for Inactive Covered Individuals
for whom you wish to obtain Medicare coverage information.
You may submit your initial Non-MSP Input File at any time during the first quarter you go live
with production data as long as testing has been successfully completed.
N and D records can be mixed together on one “logical” file between the same header and trailer
records. S records must be submitted on their own logical file with their own header and trailers.
S records cannot be mixed in the same logical file as N/D records. RREs may send in retiree files
for multiple plan sponsors (employers) for multiple RDS applications. The RDS application
number goes on the header record of the Non-MSP Input File. So, if you are submitting retiree
files for multiple plan sponsors, you must put the S records associated with each application
number in separate logical files separated by the corresponding header and trailer records. All of
these logical files can either be submitted separately or be concatenated together and submitted
in one ”physical” file as shown in MMSEA Section 111 Basic GHP Reporting Option Files
(Table 6-1). However, only one logical Non-MSP Input File with N/D records will be accepted
per month. Multiple Non-MSP Files with S records will be accepted and are to be sent on the
frequency required by the RDS Center. If you are not using the Non-MSP File to submit RDS
retiree files, then one Non-MSP File can be submitted per month with a mixture of N and D
records.

Figure 7-3: Non-MSP File Structure

7-70
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

7.4.5 Update Non-MSP Input File Submissions

An update Non-MSP Input File reflects any changes from the last submission including new
enrollees (subscribers and dependents) that are now Inactive Covered Individuals with drug
coverage under your plan, changes to previously submitted drug or subsidy records, corrections
to previously submitted records, updates to report on a coverage termination date, and new query
records. Update files containing N and D records may be submitted on a monthly or quarterly
basis. No specific submission timeframe is assigned for Non-MSP Input Files. The only
restrictions are that N and D records must be submitted on one input file and files with N and D
records cannot be sent more often than once per calendar month.
RDS retiree files submitted via S records should be sent in separate Non-MSP Files with their
own header and trailer records reflecting the associated RDS Application Number. Multiple
Non-MSP Files with S records will be accepted and are to be sent according to the frequency
required by the RDS Center.
Your Non-MSP Input update file may contain N query records for Inactive Covered Individuals
for whom you wish to obtain Medicare coverage information.

7.4.5.1 Add, Delete, Update Transactions

Add, update and delete records are identified by a value in the Transaction Type (Field 21) on
your Non-MSP Input File. They do not apply to N query records. These transactions are
processed on Non-MSP Input Files in very much the same manner as described previously for
the MSP Input Files.
Add Transactions
An “add” record or transaction is defined with a ‘0’ (zero) in the Transaction Type (Field
21). An add is a new record of coverage information that the BCRC has not posted to the
Medicare Beneficiary Database (MBD). D records accepted and added as supplemental drug
coverage to the MBD receive a ‘01’ D/N disposition code (Field 48) in your Non-MSP
Response File you receive back from the BCRC. An add transaction could be a record never
sent before or a record that was sent before but not accepted due to errors or the individual
not being a Medicare beneficiary at the time of processing.
Update Transactions
An “update” record or transaction is defined with a ‘2’ in the Transaction Type (Field 21).
An update transaction is sent when you need to correct information on a record previously
accepted and added as a supplemental drug record to MBD for which you received a ‘01’
disposition code in your Non-MSP Response File.
To successfully update a previously added record, you must match on the key fields of the
supplemental drug or subsidy record. Please refer to the Record Matching Criteria Section 7.4.3
of this guide. The BCRC will use this criterion for update and delete transactions you send. You
must save the Medicare ID (HICN or MBI) returned to you on the response files in your internal
system and use it on subsequent update and delete transactions.
Delete Transactions
A “delete” record or transaction is defined with a ‘1’ in the Transaction Type (Field 21).
Deletes are used to remove erroneous records. A delete transaction is sent to remove a
supplemental drug or subsidy record previously posted to the MBD from an add transaction

7-71
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

that was created in error. If your add transaction did not result in a ‘01’ disposition code,
there’s no need to delete it even if it was previously sent in error.
To successfully delete a previously added record, the BCRC must match on the key fields of
the supplemental drug or subsidy record. Please refer to the Record Matching Criteria
Section 7.4.3 of this guide. The BCRC will use this criterion for update and delete
transactions you send. You must save and use the Medicare ID returned to you on the
response files in your internal system and use it on subsequent update and delete transactions.
How to Report a Coverage Termination Date for Inactive Covered Individuals
If your coverage for an Inactive Covered Individual previously sent and accepted ends, you
must send an update record with the Termination Date (Field 11). For Inactive Covered
Individuals, the submitted Termination Date should be the date the individual’s GHP
coverage ends. Please see the following example: The BCRC will update the supplemental
drug or subsidy record termination date. Do not send a delete transaction in these cases as
that will remove the record entirely as though the coverage never existed and result in
potential erroneous claims payment.
Correcting Supplemental Drug Record Key Information - When to Send a Delete and
Add to Make Corrections
If you need to correct one of the key matching fields used for supplemental drug records,
you need to follow a special process to make this update. First, a delete transaction must be
sent in your file to remove the previously added record. The delete transaction should then be
followed by an add transaction in the same file to add the record back with the corrected
information.
Note 1: RREs only need to correct the Medicare ID/SSN in cases where an incorrect person
was submitted and accepted on the input record. Medicare IDs may be changed by the Social
Security Administration at times but the BCRC is able to crosswalk the old Medicare ID to
the new Medicare ID. Therefore, in those instances where the correct person was previously
submitted and the Medicare ID changes for that person at a later date, the RRE does not need
to correct the record. In fact, updates may continue to be sent under the original Medicare ID
submitted. The BCRC will always return the most current Medicare ID on response records
and RREs are encouraged to update their systems with that information and use it on
subsequent record transmissions.
Note 2: If a record was previously submitted and accepted with only a SSN, and the RRE
obtains the Medicare ID on the response file, the RRE should not send a “Delete” and “Add”
to update the beneficiary’s information with the Medicare ID. The record has already been
stored under both the SSN and Medicare ID by the BCRC. Subsequent transactions for the
record must be submitted with the Medicare ID.
Changing Coverage Information on a Supplemental Drug Record
If coverage information changes on a subsequent date after a supplement drug record has
been posted by the BCRC, then:
• Submit an update transaction with the old values and a termination date reflecting the last
day the information was true.
• Submit an add transaction with an effective date equal to the date the changed value
became effective (the day after the termination date in the update record previously
described).
7-72
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

For Non-MSP reporting purposes, changed coverage information referenced above includes:
• Coverage Type
• Relationship Code
• Rx BIN
• Rx PCN
• Rx Group Number
• GHP Number
• Individual Policy Number
• Rx Insured ID Number

7.4.6 Detailed Non-MSP Input File Requirements

• Non-MSP Input Files must contain properly formatted header, detail and trailer records
as defined in Appendix C.
• Non-MSP Input Files may be submitted on a monthly or quarterly basis.
• Non-MSP Input Files must be received on at least a quarterly basis in order to be
considered compliant with the requirements for the Expanded Reporting Option unless
you are submitting supplemental drug coverage on E02 under a COBA.
• Only Section 111 responsible reporting entities that registered for the Expanded
Reporting Option may submit Non-MSP Input Files.
• A Non-MSP Input File must contain at least one D or S record. It may not be used
exclusively for querying about Medicare coverage with N records only.
• A single Non-MSP Input File may contain D and N records. S records are to be submitted
on separate files.
• A Non-MSP response file for N and D records will be generated within 14 calendar days
after the day of release into the system for processing. A response file will be generated
when all records have been processed or after 14 calendar days. If all records have not
been applied, a disposition code will be returned indicating what records should be
resent.
• Non-MSP Response Files for S records will be returned after the BCRC has received a
response from the RDS Center.
• The initial Non-MSP Input File should contain D records for all Inactive Covered
Individuals who previously had open prescription drug coverage under your plan, even if
it has since been terminated, and who currently have active prescription drug coverage
under your plan as of the date of submission.
• The subsequent, update files should include D records for any Inactive Covered
Individual you have added to your plan since the last file submission.
• The subsequent update files must include updates to any previously submitted D and S
records that have changed since the last submission.
• Update files must contain resubmission of any records found in error on the previous file
(Disposition Codes SP) with corrections made.
Please refer to the Processing Response Files Section 7.4.7 for more information.

7-73
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

• Update files must contain resubmission of any records that received Disposition Codes
‘ID’ or ‘51’ on the previous file submission response, with corrections applied as needed.
Please refer to the Processing Response Files Section 7.4.7 for more information.
• Email notifications will be sent to the Account Manager for the RRE ID when the file has
been received and when a response file has been transmitted or is available for download.
• CMS recommends that RREs send a covered individual’s Medicare ID (HICN or MBI)
on Non-MSP Input File records whenever it is available. The Medicare ID is the
preferred data element for matching purposes. RREs are encouraged to obtain Medicare
IDs from Medicare beneficiaries they cover and must use the Medicare IDs passed back
to them by the BCRC on response files.

7.4.7 Processing Response Files

For every Non-MSP Input File you send to the BCRC for Section 111 reporting, the BCRC will
send you a response file in return. The Non-MSP Response File specifications are in Appendix
C. The response file will be transmitted back to you in the same manner that you sent your input
file. Response files for Non-MSP Files submitted with N and D records will be returned within
14 days of receipt of your input file. (See the later section of this guide on response files for Non-
MSP Files with RDS retiree S records.) The response file contains a header record, followed by
detail records for each record you submitted on your input file, followed by a trailer record that
contains a count of the detail records supplied. This count does not include the header and trailer
records. In some cases, which will be explained in later sections, you may receive more than one
detail response record for the input record you sent, but usually it will be one for one. The
response file detail records consist of the same data elements in the input file you sent, with
corrections applied by the BCRC, the disposition and error codes which let you know what the
BCRC did with the input record, as well as Medicare Part A, B, C and D coverage information.
You must develop processing to react to the response file. Disposition and error codes are shown
in Appendix D.

7.4.7.1 Part D Eligibility and Enrollment Data

In addition to information on Medicare Part A, B and C coverage, in the Non-MSP Response
Files there are five related fields that can have information about current Medicare Part D
eligibility and enrollment.
Part D Eligibility Start Date (Field 35). This will be the first date a Medicare beneficiary can
enroll in Part D. It is almost always the effective date of coverage for the beneficiary’s Part A or
Part B participation. Information in this data field does not show that a beneficiary has enrolled
in Part D.
Part D Eligibility Stop Date (Field 36). This is the date that a Medicare beneficiary’s right to
enroll in Part D has ended, for any reason.
Current Medicare Part D Plan Contractor Number (Field 41). This identifies the
beneficiary’s current Part D Plan contractor number.
Current Medicare Part D Enrollment Date (Field 42). This is the effective date of a Medicare
beneficiary’s most recent enrollment in Part D. It is the current first date the beneficiary can
receive Part D benefit coverage.

7-74
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Current Medicare Part D Plan Termination Date (Field 43). This is the last date a Medicare
beneficiary can receive Part D benefit coverage from the beneficiary’s current Part D plan. After
this date the beneficiary is no longer enrolled and can no longer receive benefit coverage from
the (most recent former) Part D plan.
Non-MSP Response File Fields 42 and 43 tell you whether a beneficiary has actually chosen Part
D coverage, and the period of time the current benefit coverage is in force. For Section 111
RREs, these two fields are the most immediate indicators of Part D coverage for Inactive
Covered Individuals.

7.4.7.2 Processing “D” Response Records

Every Non-MSP Input File D record will receive a disposition code in the D/N Disposition Code
(Field 48) on the corresponding response file record and you must take the following actions:
• Records marked in error with an ‘SP’ D/N disposition code must be corrected and resent
on your next submission. Error codes are provided in Fields 44 – 47 on the Non-MSP
Response File record. An explanation of the error codes is in
Appendix D.
• If a record was rejected with an N/D disposition code of ‘ID’ or ‘51’, which indicates the
Inactive Covered Individual could not be matched to a Medicare beneficiary, you must
continue to resend current information for the individual in subsequent file submissions
until it is accepted, your coverage for this individual is terminated, or the individual no
longer meets the definition of an Inactive Covered Individual (e.g. returns to work).
• An N/D disposition code of ‘51’ will also be returned if neither a Medicare ID (HICN or
MBI) nor SSN was submitted on the input record. You must obtain a valid Medicare ID
or SSN for the individual and resubmit the record in your next file submission.
• Records accepted with a ‘01’ N/D disposition code have been added by the BCRC as
drug coverage supplemental to Medicare on the MBD and will be used in Medicare Part
D claims processing. The following fields may contain updated information from the
BCRC based on Medicare data and could be used to update your internal files:
• Medicare ID (HICN or MBI)
• Inactive Covered Individual/Beneficiary Name
• Date of Birth
• Gender
Note: You must store the Medicare ID returned on the Non-MSP Response File in your internal
system and are required to use it on future transactions.
In addition, records returned with a ‘01’ disposition code will contain the following information
which you may use in your claims processing for coordination of benefits and proper claim
processing:
• Supplemental Drug Record Effective and Termination Dates – start and end dates for the
period of time your drug coverage is secondary to Medicare Part D and Medicare should
pay first.
• Reason for Medicare entitlement
• Beneficiary Date of Death

7-75
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

• Medicare Part A, B, C and D Coverage Dates

• End Stage Renal Disease (ESRD) information

7.4.7.3 Processing “N” Response Records

Every Non-MSP Input File N record will receive a disposition code in the D/N Disposition Code
(Field 48) on the corresponding response file record and you must take the following actions:
• Records marked in error with an ‘SP’ D/N disposition code must be corrected and resent
on your next submission. SP and Rx Error codes are provided in Fields 44–47 on the
Non-MSP Response File record. An explanation of the error codes is in Appendix D.
• If a record was rejected with an N/D disposition code of ‘ID’ or ‘51’, which indicates the
Inactive Covered Individual could not be matched to a Medicare beneficiary, you must
check the information you sent for accuracy and then resend as appropriate.
• Records accepted with a ‘01’ N/D disposition code have been matched by the BCRC to a
Medicare beneficiary and the beneficiary’s Medicare coverage information has been
provided on the response record. The following fields may contain updated information
from the BCRC based on Medicare data and could be used to update your internal files:
• Medicare ID (HICN or MBI)
• Inactive Covered Individual/Beneficiary Name
• Date of Birth
• Gender
Note: You must store the Medicare ID returned on the response file in your internal
system and are required to use it on future transactions.
N records returned with a ‘01’ disposition code will contain the following information
which you may use in your claims processing for coordination of benefits and proper
claim processing:
• Reason for Medicare entitlement
• Beneficiary Date of Death
• Medicare Part A, B, C and D Coverage Dates
• End Stage Renal Disease (ESRD) information

7.4.7.4 Processing “S” Response Records

Please refer to the RDS Retiree File Submission Section 7.4.9.

7.4.7.5 Non-MSP Input File Threshold and Severe Errors

Threshold Errors
After completion of data quality edits, the BCRC will check your Non-MSP Input File to ensure
it does not exceed any threshold restrictions (please see Table 7-10). Threshold checks are
performed to identify a file that may be in error. In some cases, there could be a reasonable
explanation. The file threshold checks include:
• More than 5% of the total D records are delete transactions.
• More than one Non-MSP Input File with N/D records was submitted during a one-month
period of time.
7-76
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

• No D or S records are included in the file. You may not send a Non-MSP Input File with
only N query records. The Non-MSP Input File must contain supplemental drug coverage
records. If you only have a need to query for Medicare entitlement, then the Query Only
File format must be used.
A file that exceeds the threshold checks will be suspended from further processing until the
suspension is overridden by your EDI Representative. An email will be sent to the Account
Manager for the RRE ID to inform him/her of this suspension. You must contact your EDI
Representative to discuss and resolve file threshold errors. Your file may be released for
processing or, if sent in error, deleted by your EDI Representative in which case you may resend
a corrected file as instructed by your EDI Representative.

Table 7-10: Threshold Errors

Threshold Error Explanation/Correction
5% or more of records are delete transactions Examine use of the delete function. Do not submit deletes
when GHP coverage ends. Submit updates with
termination dates instead. Only submit deletes to remove
erroneous records previously accepted with a ‘01’
disposition code. Very small files may suspend for very
few delete records. If the delete transaction was used
correctly, your EDI Representative will release the file for
normal processing.
20% or more of records failed record level edits Error messages will display in the threshold email.
Contact your EDI Representative to discuss most common
errors found. Your EDI Representative will provide
further instruction. Very small files may suspend for very
few records in error. In that case, your EDI Representative
may release the file for processing.
Multiple files submitted. Exceeds allowed Only one Non-MSP Input File with N/D records may be
submission frequency. submitted per month.
No Supplemental Drug or RDS Subsidy records Non-MSP Input Files cannot be submitted with only ‘N’
included with file query records. The Non-MSP Input File cannot be used
solely for querying.
Another file in process for/still processing from A file of the same type submitted previously is still
prior submission period processing. This prior file must complete processing
before the new file can be released by your EDI
Representative.
File held via watch list Your RRE ID has been put on a watch list by the BCRC
due to past issues with erroneous file submissions. Contact
your EDI Representative to resolve.
Severe Errors
Files detected with severe errors will also suspend from processing. An email will be sent to the
Account Manager for the RRE ID regarding the severe error found. You must contact your EDI
Representative to discuss the situation. The EDI Representative will then delete the file and
provide you with instructions as to when to send a corrected file. Severe errors include:
• Missing or improperly formatted header or trailer records
• Record counts that do not match those actually submitted

7-77
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Table 7-11: Severe Errors

Severe Error Explanation/Correction
File has invalid RECFM/Record Format Files must be submitted in a fixed-block format with all
records of the same fixed length.
File has invalid LRECL/records with invalid record The record length of each record on the file must match
lengths that specified in the record layouts in the appendices.
All unused fields must be set to default values and filler
at the end of the record must be filled with spaces to the
end of the record length.
File empty A file with no header, detail and trailer records was
transmitted to the BCRC. Transmission may have failed
or there was a problem at the RRE with the creation of
the file. If you have nothing to report for a quarter, you
may submit a header record, no detail records and a
trailer record with a zero-record count.
Header record was missing Header record starting with the characters ‘H0’ was not
present prior to encountering a detail or trailer record.
Do not submit detail records with Medicare IDs (Health
Insurance Claim Numbers [HICNs] or Medicare
Beneficiary Identifiers [MBIs]) starting with ‘H0’ or
‘T0’ as these are not valid and might be confused with
header and trailer records.
Note: The Medicare ID is also known as the Medicare
Number to CMS’ Medicare beneficiaries.
Header record does not match filename –or- The RRE ID on the file header record does not match
Header record RRE ID does not match mailbox the RRE ID under which it was uploaded. The file was
RRE ID uploaded via HTTPS under the wrong RRE ID or sent
to the wrong SFTP mailbox.
Header record not formatted properly Refer to the file layouts in the appendices for proper
header record formats. In particular, the header indicator
and file type must be valid, RRE ID must be numeric
with leading zeroes as appropriate, date fields must
contain a valid date and be formatted as CCYYMMDD.
Trailer record missing No trailer record was found at the end of the file or prior
to the system encountering another header record
beginning with ‘H0’. Do not submit detail records with
Medicare IDs starting with ‘H0’ or ‘T0’ as these are not
valid and might be confused with header and trailer
records.
Trailer record not formatted properly Refer to the file layouts in the appendices for proper
trailer record formats. In particular, the trailer indicator
and file type must be valid, RRE ID must be numeric
with leading zeroes as appropriate, date fields must
contain a valid date and be formatted as CCYYMMDD,
and the record count must be numeric with leading
zeroes as appropriate.
Trailer record does not match header record The RRE ID and/or file submission dates on the header
and trailer records are not the same.
Trailer record count does not match count of The trailer record count should only include the number
records in file of detail records on the file. Do not include the header
and trailer records in this count.

7-78
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Severe Error Explanation/Correction

Non-MSP: Detail record action code not valid for Action type on a Non-MSP Input File Detail Record is
header record file type invalid. Detail record action types must be equal to D,
S, or N.
Test file with more than 100 records Test files must be limited to 100 detail records or less.
Resubmit a new test file with fewer records.
Production file reporter status not equal to P A production file was received for an RRE ID that is not
in a production status. Make sure your profile report has
been signed by your Authorized Representative and
returned to the BCRC. Verify testing requirements have
been met. If so, contact your EDI Representative to
request that your RRE ID be changed to a production
status.
Reporter in discontinued/inactive status A test or production file was received but your RRE ID
has been deactivated. File submitted in error. Check to
see that the proper RRE ID was used and that the file
was sent to the proper RRE ID mailbox/dataset. If this
RRE ID is still in use, ask your EDI Representative to
correct the status of your RRE ID.

7.4.7.6 End Stage Renal Disease (ESRD)

In order to allow Section 111 RREs to better coordinate benefits for Medicare beneficiaries
related to End Stage Renal Disease (ESRD), the BCRC will provide ESRD data fields on your
Non-MSP Response File for Inactive Covered Individuals. These fields are the ESRD Coverage
Period Effective and Termination Dates, the First (oldest) Dialysis Date, the Self-Training Date,
the most recent Kidney Transplant Date, and the most recent Kidney Transplant Failure Date.
Please refer to fields 55-60 in the Non-MSP Response File specifications in Appendix C.
For an individual with ESRD there is a 30-month coordination of benefits period for ESRD
where the patient’s GHP coverage may be primary to Medicare. Subsequent to that 30-month
period, Medicare becomes the primary payer regardless of the patient’s other GHP coverage.
There are conditions that must be met in order for a patient to receive Medicare benefits and
coverage for an ESRD diagnosis. Refer to https://www.cms.gov/ESRDGeneralInformation/
https://www.cms.gov/OrigMedicarePartABEligEnrol/ and
https://www.cms.gov/Medicare/Coordination-of-Benefits-and-Recovery/Coordination-of-
Benefits-and-Recovery-Overview/End-Stage-Renal-Disease-ESRD/ESRD.html for more
information related to the coordination of benefits with Medicare for ESRD. This topic is also
covered in the computer-based training curriculum made available to RREs as described in
Chapter 13.

7.4.8 True-Out-of-Pocket (TrOOP) Facilitation RxBIN and PCN Codes

Section 111 responsible reporting entities that choose the Expanded Reporting Option and
provide supplemental prescription drug coverage to Inactive Covered Individuals will need to
obtain TrOOP Facilitation RxBIN or PCN codes to route claims through the Part D Transaction
Facilitator (i.e., the TrOOP Facilitator). The TrOOP Facilitation RxBIN or PCN codes are
routing numbers used to flag claims for coverage supplemental to Medicare Part D that will be
paid by Section 111 reporters or their agents. As it is being routed to the pharmacy, the TrOOP
Facilitation RxBIN or PCN will enable the TrOOP Facilitation Contractor to identify a Part D
supplemental claim, capture it, and transmit the supplemental paid claim amount to the

7-79
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

appropriate Part D Plan to support the Plan’s TrOOP calculation responsibilities. To route these
claims through the TrOOP Facilitation Contractor, you may use a separate and unique RxBIN by
itself or a unique PCN in addition to your existing RxBIN.
The organization that issues the original RxBIN is the American National Standards Institute, or
ANSI. ANSI can be contacted through its web address: https://www.ansi.org.
A different organization, the National Council for Prescription Drug Programs (NCPDP) issues
the Processor Control Number, or PCN. For TrOOP routing you can use a new or additional
PCN in lieu of an additional RxBIN. The NCPDP can be contacted through its Web address:
https://www.ncpdp.org.

7.4.9 RDS Retiree File Submission

This section only applies to you if you plan to submit retiree files to the Part D Retiree Drug
Subsidy (RDS) Center on behalf of a Plan Sponsor (usually an employer) through your Section
111 reporting process. If you have no plan to do that, you may ignore the information in this
section.
You may use Section 111 reporting as an alternative method of providing retiree drug subsidy
enrollment files to the RDS Center. After enrollment with the RDS program, a Plan Sponsor can
use Section 111 for its necessary data transfer and management of retiree files with the RDS
Center. Plan Sponsors wishing to receive the Part D Retiree Drug Subsidy for retiree drug
coverage must submit an initial application to the RDS Center, a requirement separate from the
Section 111 process. For more information and complete requirements related to the retiree drug
subsidy please visit: https://rds.cms.hhs.gov/. The RDS User Guide can be found under the User
Guides menu option on this website.
As part of the application process, the Plan Sponsor must send an initial enrollment file of all
retirees and dependents for whom they wish to claim the subsidy. The initial retiree file will be
followed by regularly scheduled update files containing adds, updates and deletes.
Section 111 responsible reporting entities submitting retiree files for RDS may opt to do so using
records with the ‘S’ Action Type in the Non-MSP Input File format. ‘S’ records require
essentially the same data elements required for ‘D’ records. Non-MSP Input Files containing S
records must contain the RDS Application Number, a data element the RDS Center will assign to
a Plan Sponsor at the start of the RDS application process, in the associated header record for the
file. Since the RDS Application Number is part of the Non-MSP header record, you may submit
multiple Non-MSP files for each RDS Application Number on the frequency prescribed by the
RDS Center. These multiple files can be submitted separately or within the same physical file as
long as the files are separated by the appropriate header and trailer records as shown in
Figure 7-4.
Do not put N and D records on a Non-MSP File containing S records.

7-80
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

Figure 7-4: Non-MSP File Structure for RDS Retiree Files

The BCRC essentially acts as a pass through and will send S records directly to the RDS Center
for processing. The RDS Center will determine whether the covered individuals included on S
records are eligible for the subsidy (Part D eligible, but not enrolled in Part D). On the response
records, the RDS Center will indicate whether a covered individual was accepted (eligible to be
included as part of the plan sponsor’s subsidy population) or rejected, by putting a ‘Y’ or ‘N’ in
the RDS Determination Indicator (Field 54). If the covered individual is not accepted for the
subsidy, or the record is in error, corresponding reason/error codes will be posted in the RDS
Reason Code (Field 53). The BCRC will populate the S response record with Medicare Part A,
B, C and D coverage information as applicable. The BCRC will then return the S records to the
Section 111 reporter on a Non-MSP Response File.
Splits – Multiple S Response Records
Because periods of eligibility can be interrupted, or a retiree is not eligible for the subsidy for the
entire year, you may get more than one S response record for a given submitted S record for a
beneficiary/retiree. If this is the case, the RDS Split Indicator (Field 52) will be set to ‘Y’ and the
RDS Start and End Dates in Fields 50-51 will reflect the split periods on each of the response
records. Each response record will contain your original DCN (document control number) in the
response Field 21. Each response record will contain the RDS Determination and Reason Codes
that apply to the date span specified. For example, if the S record was sent to claim the subsidy
for 1/1/2009 through 12/31/2009 but the retiree is not entitled to Medicare until 4/1/2009, one
response record will include RDS Start and End Dates for 01/01/2009 through 03/31/2009 with a
RDS Determination Indicator of N and a RDS Reason Code of 11 (person is not yet eligible for
Medicare). The second response record will have dates 04/01/2009 through 12/31/2009 covering

7-81
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

the remainder of the plan year with an RDS Determination Indicator of ‘Y’ and a blank RDS
Reason Code.
RDS Determination and Reason Codes
When the original GHP data sharing process was first expanded to include RDS reporting
capabilities, the BCRC converted the RDS-specific Determination and Reason Codes to the
existing data sharing process Disposition and SP Error Codes that appear in Field 29 (S
Disposition Code) and Fields 44-47 (Error Codes) of the Non-MSP Response File. RDS has
since added new RDS Reason Codes that could not be cross-walked to the existing codes, which
are now the Section 111 Disposition Codes. Therefore, the Non-MSP Response record layout
now includes the actual RDS Reason Code in Field 53 and the RDS Determination Indicator in
Field 54 in addition to the cross-walked fields. Field 53 and 54 contain the same codes you
would receive if you submitted the RDS retiree files directly to the RDS Center and not through
the Section 111 process.
You should use Fields 53 and 54 for your S record response processing. For questions about the
RDS codes please contact the RDS Center directly or visit https://rds.cms.hhs.gov/. The RDS
User Guide can be found under the User Guides menu option on this website. The RDS User
Guide contains complete and most current information regarding RDS Determination and
Reason Codes.
Converting an “S” Record to a “D” Record
Prior to transmitting the Non-MSP Response File back to you, when the BCRC receives S record
responses from the RDS Center, it will screen those responses for covered individuals who do
not qualify to be counted in the Plan Sponsor’s drug subsidy because they are enrolled in Part D.
These individuals will then be considered to have other drug coverage supplemental to their Part
D coverage. Accordingly, using the information you sent on the S record, the BCRC will add a
supplemental drug coverage record to the MBD (as it would with a standard D record). You will
receive one response record with a D in the Action Type Field 24 and S in the Original Action
Type Field 23. The RDS Determination and Reason Codes in Fields 53 and 54 will indicate why
the record was rejected for the subsidy, Field 29 will have the BCRC Disposition Code for the S
record, and the D/N Disposition in Field 48 will indicate the results of posting the record as a
supplemental drug record. The response record will contain your original DCN (document
control number) in Field 21. You will be expected to submit updates and/or deletes to maintain
this supplemental drug record going forward on your subsequent Non-MSP Input Files with D
record action types.
Unsolicited RDS Response Files or Records
The Non-MSP Response File format is also used to send you unsolicited response files
originating from the RDS Center. These transmissions from the RDS Center will notify you that
significant data you previously submitted, that may affect the Plan Sponsor’s ability to claim the
subsidy for an individual, has changed. For example, the retiree may have enrolled in Part D
making them ineligible for the subsidy from the Part D enrollment date going forward.
Unsolicited RDS responses are designated by the “RDSU” file type in Field 3 in the header of
the Non-MSP Response File and will be sent separately from the regular Non-MSP Response
Files (‘NMSR’ in Header Field 3). Table 7-12 lists the RDS Reason Codes you may receive in
Field 53 on an unsolicited response file record. The RDS Start and End Dates in Field 50-51 may
also have been adjusted. In addition, the RDS Determination Indicator may show a changed
value of ‘N’ instead of ‘Y’ for Reason Codes 10, 11, and 12. The Plan Sponsor must adjust the

7-82
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

periods for claiming the subsidy for affected individuals using this information or resend the
original records for proper subsidy determination. Please refer to the RDS User Guide found
under the User Guides menu option on https://rds.cms.hhs.gov/ for more information.

Table 7-12: RDS Reason Codes Returned on Unsolicited Response File Record
RDS Reason Code Description
10 Enrolled in Part D. The retiree cannot be covered under the RDS program
because the retiree is/was enrolled in Medicare Part D during the coverage period
provided by the Plan sponsor.
11 Not eligible for Medicare. The retiree cannot be covered under the RDS
program because the retired is/was not enrolled/entitled to Medicare during the
coverage period provided by the Plan sponsor.
12 Beneficiary is deceased.
204 Beneficiary attempted to enroll in Part D and received an initial rejection.
The retiree tried to enroll in Medicare Part D when (s)he was already covered
under the RDS program and as a result this initial attempt to enroll in Part D was
denied.
The Plan Sponsor may counsel the beneficiary that they have equal or better
prescription drug coverage through the RDS program. The Plan Sponsor will not
be able to claim the subsidy for the beneficiary if the retiree overrides the denial
and enrolls in Part D.
21 New Medicare information has been received – resend record. After an initial
rejection of the retiree’s record, the RDS Center has now been notified of a
change in the retiree’s Medicare enrollment/entitlement status. The Plan sponsor
should resubmit the retiree data on its next monthly update to determine if the
retiree is now eligible for RDS program coverage.

7.5 Testing the Section 111 Reporting Process

7.5.1 Overview of the Testing Process
RREs must pass a testing process prior to sending production files for Section 111. The testing
process will ensure that the RRE has developed an adequate system internally to capture and
report data to the BCRC as well as process the corresponding response files. A series of test files
will be submitted to the BCRC in order to verify that the RRE can transmit files successfully in
the correct format, accept and process response files, and properly submit add, update, and delete
records. If the RRE is using an agent to test, the agent must submit and pass the testing process
on behalf of the RRE. Testing must be completed for each RRE ID registered.
RREs will submit test files in the same manner as the method they choose for submitting
production files (HTTPS, SFTP or Connect:Direct). All RREs will be able to monitor the status
of the testing process on the COBSW no matter which method is chosen.
Note: When using the HTTPS file transmission method, only files with the file extension of .txt
are allowed for uploading. Any other file type will generate an Invalid File error message.
Your EDI Representative will be your main point of contact to assist you throughout the testing
process.

7-83
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

7.5.2 General Testing Requirements

• RREs must complete the registration and account setup process on the Section 111
COBSW and return the signed profile report to the BCRC before testing may begin. A
signed profile report must be returned for each RRE ID registered.
• Testing must be completed for each RRE ID registered.
• The RRE must transmit test files to the BCRC in the same transmission method as that
chosen for production files.
• The BCRC will maintain a test environment that contains a mirror image of the COB
Beneficiary Master Database containing all beneficiary information the BCRC has in
production and programs that will mimic the way the files would be processed in
production, with the exception of actually updating other Medicare systems and
databases.
• RREs will send actual information for covered individuals on test files in order to test
realistic situations. However, no production Medicare databases or systems will be
updated from test file submissions.
• Test files must be limited to no more than 100 records. Test files with more than 100
detail records will be rejected and not processed.
• The system will apply the same file error threshold checks to test files as those applied to
production files.
• RREs choosing to transmit files via SFTP will receive a test submission
mailbox/directory separate from their production submission mailbox/directory on the
Section 111 SFTP server. RREs choosing to transmit files via HTTPS will do so using
the “Upload File” action on the RRE Listing page after logging on to the Section 111
COBSW application. The Upload File action requires you to indicate whether you are
submitting a test or production file and the system will place the file automatically in the
proper directory for you. RREs choosing Connect:Direct will send test files to a different
destination dataset name than production files.
• The BCRC will return a test response file within one week of submission of a test input
file.
• The BCRC will track the progress made with test files, display results on the Section 111
COBSW and put the RRE ID in a “production” status after the testing requirements have
been successfully completed. The RRE may continue to test with additional test file
submissions after being placed in a production status.
• The results of MSP Input File testing will trigger the transition of an RRE from a testing
status to a production status. However, testing of the Non-MSP and Query Only Files is
highly recommended.
• Once an RRE has moved to a production status, any subsequent test files received will
continue to be processed by the BCRC and results will be displayed on the COBSW. Test
response files will be produced and transmitted. In other words, RREs may continue to
submit test files after the RRE ID has changed to a production status and even after
production files have been submitted. This will allow RREs to test subsequent changes to
their internal reporting process without disruption to production reporting.
• Testing progress and completion dates will be tracked and reported in the system by the
BCRC. The COBSW will provide a Testing Results page to show the status of test file
processing. Information regarding the attainment of test requirements will be available
7-84
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

there for review. All users associated with the RRE ID account on the COBSW will be
able to monitor the status of the testing process on the COBSW. If testing is not
completed by an RRE by the production file submission date, an email notification will
be sent to the Authorized Representative and Account Manager. RRE ID accounts that
have been in a “testing” status for more than 30 calendar days will receive a warning
email indicating that the account may be at risk of non-compliance with the Section 111
Mandatory Reporting requirement. This is for informational purposes only. Please be
sure that your EDI Representative is kept informed of your testing progress and any
issues that you have encountered.
• If you run the risk of not completing testing in time to submit required information on
your initial MSP Input File, please notify your EDI Representative immediately. Even
after the RRE ID has been put in a production status, you may continue to send test files
for any file type as you deem necessary.
• If an RRE ID is not yet in a production status, production files submitted for any file type
will be rejected.
• Once the MSP Input File test requirements have been met for the RRE ID and your EDI
Representative has moved the RRE ID to a production status, an email will be sent to the
RRE’s Authorized Representative and Account Manager to notify them of the change in
status and that production files may now be submitted.

7.5.3 MSP Input File Testing

A test TIN Reference File must be submitted prior to or with your test MSP Input Files. RREs
are advised to submit and complete successful processing of test TIN Reference Files prior to
attempting submission of MSP Input Files as the TIN information is required for successful
processing of MSP Input Files.
GHP RREs selecting either the Basic or Expanded Reporting Option must submit at least the
following test MSP Input Files:
• A TIN Reference File with information for each TIN submitted on the MSP Input File.
• One initial MSP Input File with at least 25 add records.
• A second MSP Input File with at least 5 updates and 5 deletes for previously submitted
and accepted records. This file is submitted after the first response file returned by the
BCRC is processed.
GHP RREs selecting either the Basic or Expanded Reporting Option must process at least two
test MSP Response Files sent back by the BCRC.
GHP RREs selecting either the Basic or Expanded Reporting Option must successfully perform
the following to pass the testing process. These records must receive a ‘01’ disposition code on
corresponding response file records:
• Post at least 25 new cases with add records in one file submission.
• Complete at least 5 updates to previously posted records in one file submission.
• Complete at least 5 deletes to previously posted records in one file submission.
Note: Additional test files must be submitted until these requirements are met and as advised by
your EDI Representative.

7-85
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

7.5.4 Non-MSP Input File Testing

RREs must pass the testing requirements for processing MSP Files in order to attain a
“production” status for each RRE ID. Once the RRE ID is set to a production status, production
files of any type may be submitted. However, the BCRC strongly recommends that GHP RREs
selecting the Expanded Reporting Option submit at least the following additional test files:
• One Non-MSP Input File with at least 25 supplemental drug coverage add transactions
(D records) and 5 query records (N records).
• A second non-MSP file with at least 5 updates and 5 deletes to previously submitted drug
coverage records.
The BCRC recommends that GHP RREs selecting the Expanded Reporting Option successfully
perform the following before submitting production Non-MSP Input Files. These records must
receive a ‘01’ disposition code on corresponding response file records in order to be considered
successful transactions:
• Post at least 25 new drug coverage cases with add records in one file submission.
• Complete at least 5 updates to previously posted drug coverage records in one file
submission.
• Complete at least 5 deletes to previously posted drug coverage records in one file
submission.
Additional test files may be submitted as deemed necessary by the RRE.

7.5.5 Query Only File Testing

RREs must pass the testing requirements for processing MSP Files in order to attain a
“production” status for each RRE ID. Once the RRE ID is set to a production status, production
files of any type may be submitted. However, the BCRC strongly recommends that GHP RREs
using the query process test before submitting production Query Only Input Files. As described
previously, you may use the HEW software to produce your test Query Only Input Files and
process your test Query Only Response Files or use your own X12 translator software to create
and exchange the ASC X12 270/271 transaction set.
After processing the test Query Only Input File, the BCRC will provide you a test Query Only
Response File identifying those covered individuals that are entitled to Medicare and those
individuals not matched to a Medicare beneficiary as prescribed by the file record layouts in
Appendix B (if using the HEW software) or as documented in the Section 111 X12 270/271
companion guide. After you are satisfied with the results of the testing, you may begin
submitting regular production Query Only Input Files on a monthly basis as long as the RRE ID
is in a production status based on MSP Input File testing results.
Testing for the query process may be completed before, during or after your testing of the MSP
Input File. Testing for the query process may be completed after the RRE has been set to a
production status. Testing the MSP Input File should be your highest priority.
RREs should submit at least the following test files:
• One Query Only Input File with at least five detail records.
• Additional Query Only Input Files as needed to validate the use of the query process by
the RRE.
RREs will process at least the following test response files sent back by the BCRC:

7-86
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

• One (1) corresponding Query Only Response File.

• Additional response files as needed/requested.
The BCRC will return test Query Only Response Files within one week of submission of the test
Query Only Input File.

7.6 Summary of Steps to Register, Test and Submit Production Files

In summary, the following are the high-level steps you need to follow to set up your reporting
process for Section 111:
Complete your registration and account setup (including file transmission information) on the
Section 111 COB Secure Website (COBSW) at https://www.cob.cms.hhs.gov/Section111/ on the
internet. Register users for the COBSW.
• Receive your profile report via email indicating your registration was accepted by the
BCRC.
• Verify, sign and return your profile report to the BCRC.
• Complete your file transmission setup. If you choose SFTP/HTTPS on the COBSW, the
system will automatically create the necessary mailbox/directories. If you choose
Connect:Direct, contact your EDI Representative for information on how to establish a
connection to the BCRC via the CMS Extranet and CMSNet, and create transmission
jobs and datasets.
• Review file specifications, develop software to produce Section 111 files, and schedule
your internal quarterly submission process.
• Test your file transmission method with the BCRC.
• Test each Section 111 file type you will be submitting with the BCRC.
• Basic Reporting Option Submitters – MSP, TIN Reference and optional Query Only
Files.
• Expanded Reporting Option Submitters – MSP, TIN Reference, Non-MSP, and
optional Query Only Files.
• Submit your initial TIN Reference File and MSP Input File with all Active Covered
Individuals by your assigned production live date.
• If you are an Expanded Reporting Option submitter, submit your initial Non-MSP File
with all Inactive Covered Individuals after your assigned production live date.
• Submit your Query Only File as needed but no more than quarterly ongoing.
• Submit your quarterly MSP Input File ongoing during your assigned submission periods.
• Submit your monthly or quarterly Non-MSP Input File ongoing.
• Monitor file processing and statistics on the COBSW on a regular basis.
• Monitor emails transmitted to your Account Manager and Authorized Representative
ongoing (See Chapter 11).
• Contact your EDI Representative to resolve any technical reporting questions and issues.
• Update passwords used for the COBSW and SFTP on a regular basis (at least every 60
days.)
• Starting in January 2012, profile reports will be regenerated and emailed to the RRE’s
Authorized Representative and Account Manager on an annual basis, based on the receipt
7-87
GHP User Guide Chapter 7: GHP Mandatory Reporting Requirements

date of the last signed profile report. The RRE’s Authorized Representative must review,
sign and return the profile report to the BCRC within 30 days of receipt to confirm or
update account information and active reporting status for the RRE ID. Failure to return
the signed profile report may result in deactivation of the RRE ID.

7-88
GHP User Guide Chapter 8: Electronic Data Exchange

Chapter 8: Electronic Data Exchange

8.1 File Transmission Methods

There are three separate methods of data transmission that Section 111 responsible reporting
entities may utilize. As part of your account setup on the COBSW for Section 111, you will
indicate the method you will use and submit the applicable transmission information. Each file
type (MSP, Non-MSP, and Query Only) can be set up with the same file transmission method or
you may select a different file transmission method for each. However, the method selected for
the file type will be used to transmit the corresponding response file back to the RRE by the
BCRC.
Generally speaking, if you expect to be transmitting files with more than 24,000 records on a
regular basis, it is suggested that you use either the Connect:Direct or SFTP methods described
below. HTTPS is more suitable for use with smaller files due to the time it may take to upload
and download files during an active user session on the Section 111 COBSW using that method.

8.1.1 Connect:Direct (NDM via the CMSNet)

RREs with a very large transmission volume may wish to consider using Connect:Direct
(formerly known as Network Data Mover or NDM) via a connection to the CMS Extranet
Network and CMS’ private CMSNet network hosted by Verizon Business Network Services.
Please contact the EDI Department at (646) 458-6740 or your EDI Representative for
information on how to establish this connectivity. You are encouraged to do this as soon as
possible since this setup can take a significant amount of time. There are implementation
costs and ongoing charges related to this transmission method.
During COBSW account setup, you will select the Connect:Direct option and provide the dataset
names you want the BCRC to use when sending back response files. You must then contact your
EDI Representative to complete the setup. After your registration has been processed and
connectivity established, the BCRC will email a profile report to confirm your Section 111
destination dataset names to which you will send your input files. If you have already registered
for Section 111 under another file transmission method and wish to change to Connect:Direct,
contact your EDI Representative.
The dataset naming convention you will use to transmit files to the BCRC under this method is:
Production Files
For MSP Input/TIN Reference Files: PCOB.BA.MRMSP.Rxxxxxxx(+1)
For Non-MSP Files: PCOB.BA.MRNMSP.Rxxxxxxx(+1)
For Query-Only Files: PCOB.BA.MRQRY.Rxxxxxxx(+1)

8-1
GHP User Guide Chapter 8: Electronic Data Exchange

Test Files
For MSP Input/TIN Reference Files: TCOB.BA.MRMSP.Rxxxxxxx(+1)
For Non-MSP Files: TCOB.BA.MRNMSP.Rxxxxxxx(+1)
For Query-Only Files: TCOB.BA.MRQRY.Rxxxxxxx(+1)
Where “xxxxxxx” is the last 7 digits of your Section 111 RRE ID assigned to you after
registration as shown on your profile report.
The information your Account Manager must provide, for each file type, during Section 111
COBSW account setup is as follows:
• Test and production destination dataset names to which you want the BCRC to send your
response files
• Optional special instructions such as file triggers you want the BCRC to use.
Note: Your Account Manager must have the destination dataset name information listed
above on hand when completing account setup on the COBSW. If this information cannot be
provided, the account setup step cannot be completed, other account information entered
during that step will not be saved and your Account Manager will have to return to perform
account setup from the beginning at a later time.

8.1.2 Secure File Transfer Protocol (SFTP)

RREs who select the SFTP method will transmit files over the Internet to and from the BCRC for
Section 111 using directories (mailboxes) created on the BCRC Section111 SFTP server.
Separate directories are set up for each RRE ID. Subdirectories are set up for test input,
production input, test response files and production response files (see below). The mailboxes
are automatically created when your Account Manager selects SFTP as the file transmission
method during COBSW account setup.
A Login ID and Password are required for the SFTP file transmission method. Any Login
ID/Password assigned to a user of the Section 111 application on the COBSW associated with
the RRE account may be used. During initial account setup on the COBSW, the RRE’s Account
Manager will create a Login ID and Password (or use his or her previously defined Login ID
when performing setup for multiple RRE IDs). The Account Manager may then log in to the site
and invite other users to be become Account Designees associated with the RRE. Each Account
Designee will obtain his or her own Login ID and Password. These same Login IDs and
Passwords are to be used for SFTP transmission. Each user of the COBSW will have one Login
ID and Password. That same Login ID and Password can be used for multiple RRE SFTP
transmissions. For example, an agent may be an Account Manager or Account Designee for
many RREs. That agent may use his or her one COBSW Login ID and Password to transmit files
for all his or her RRE clients via SFTP. The agent may also use this Login ID to log in to the
COBSW application and monitor file processing.

8-2
GHP User Guide Chapter 8: Electronic Data Exchange

Note: Passwords for the COBSW must be changed every 60 days. You must sign on to the
Section 111 Application on the COBSW in order to change your password. Failure to
maintain a current password will result in an unsuccessful SFTP file transfer. The BCRC
recommends that you login to the COBSW and perform the Change Password function
once a month to avoid password expiration.
For this transmission method, CMS has extensive experience using the Sterling
Connect:Enterprise Secure Client. The cost to you to acquire this software is nominal. However,
you may use other software as long as it is SSH v2 capable.
Here is the information you will need to configure your SFTP software to transmit Section 111
files:

Table 8-1: SFTP Software Configuration

Type of Server Standard SSH Server

Host or IP Address of Server sftp.section111.cms.hhs.gov

Port Number of Server 10022

User Credentials (ID and Password) Individual COBSW Login ID and Password
assigned to an Account Manager or Account
Designee associated with the RRE ID account
Each RRE mailbox will be defined with the following directory/subdirectories (where RREID is
the 9-digit Section 111 Reporter ID or RRE ID.) Subdirectory names are in lower case. These are
the directories to which you will send files for upload to the COBSW and from which you will
pull files for download. The BCRC will not actually transmit response files back to the RRE or
its agent. You must pull/download response files from the COBSW.
Input Files (upload):
RREID/submission/test
RREID/submission/prod
Response Files (download):
RREID/response/test/msp
RREID/response/test/non-msp
RREID/response/test/query-only
RREID/response/test/non-msp-rds
RREID/response/prod/msp
RREID/response/prod/non-msp
RREID/response/prod/query-only
RREID/response/prod/non-msp-rds
In summary, the SFTP file directory is structured as:

8-3
GHP User Guide Chapter 8: Electronic Data Exchange

• RRE ID
• submission
• test
• prod
• response
• test
• msp
• non-msp
• query-only
• non-msp-rds
• prod
• msp
• non-msp
• query-only
• non-msp-rds
Note: TIN Reference Response Files (effective October 1, 2011) are placed in the “msp” folder.
Using your SFTP client or other software (e.g. command line interface), you will sign on to the
Section 111 SFTP server, provide your credentials, navigate through the RRE ID directories and
subdirectories to which you have access and then upload or download the applicable file(s).
To navigate to an RRE ID directory, take the following steps:
• Connect to the Section 111 SFTP server using the host name/IP address and port
provided above.
• Sign on with your Section 111 COBSW Login ID and Password.
• If your Login ID is associated with more than one RRE ID, you will be presented with
the directories for each RRE ID to which the Login ID is associated on the COBSW.
Navigate (change directories) to the RRE ID for which you will be uploading or
downloading. If your Login ID is only associated with one RRE ID, skip this step.
• Within the RRE ID directory, you will find submission and response directories.
Navigate (change directories) to the submission directory to upload input files or to the
response directory to download response files.
Upload
• After going to the submission directory as described above, navigate (change directories)
to either the test or prod directory as applicable to the file you are uploading.
• Once you have navigated to the correct directory, proceed to upload your file. There is no
specific file naming convention needed. The BCRC will determine the file type from the
file contents and test/prod directory to which it’s uploaded.
Download
• After going to the response directory, navigate (change directories) to either the test or
prod directory as applicable for the response file you wish to download.

8-4
GHP User Guide Chapter 8: Electronic Data Exchange

• After selecting the test or prod directory, you will be presented with the response file
directories to choose from (msp, non-msp, query-only, and non-msp-rds). Select or
navigate to the applicable subdirectory for the response file you wish to download.
• Once you have navigated to the correct subdirectory, proceed to download the response
file. The response file naming convention used is shown below and contains a date and
timestamp. If you are automating your SFTP, you may wish to set up your software to
pull response files subsequent to a certain date parameter or do a comparison of the files
present in the directory to the files you previously downloaded so that you only pull new
response files added by the BCRC since your last access. Response files remain on the
Section 111 SFTP server for 60 days.
There is no specific naming convention needed for uploaded input files.
The BCRC will name response files according to the following convention and place them in the
corresponding subdirectories for download by the RRE or its agent:
MSP: PCOB.BA.MR.GHPMSP.RESP.Dccyymmdd.Thhmmssmm.TXT
TIN: PCOB.BA.MR.GHPTIN.RESP.Dccyymmdd.Thhmmssmm.TXT
Non-MSP:PCOB.BA.MR.GHPNMSP.RESP.Dccyymmdd.Thhmmssmm.TXT
Query: PCOB.BA.MR.GHPQRY.RESP.Dccyymmdd.Thhmmssmm.TXT
RDS: PCOB.BA.MR.GHPRDS.RESP.Dccyymmdd.Thhmmssmm.TXT
Unsolicited Resp: PCOB.BA.MR.GHPUNS.RESP.Dccyymmdd.Thhmmssmm.TXT
Where ‘Dccyymmdd’ is ‘D’ followed by a date as century/year/month/day and
‘Thhmmssmm’ is ‘T’ followed by a time as hours/minutes/seconds/centiseconds.
Response files will remain available for downloading for 60 days. Response files can be
downloaded more than once as needed. COBSW users cannot delete response files from the
COBSW SFTP server. The BCRC will remove these files automatically after 60 days.
Files submitted via SFTP to the COBSW should utilize an ASCII format. Fields within the
records are length delimited and all records are fixed length.

8.1.3 Hypertext Transfer Protocol over Secure Socket Layer (HTTPS)

Files uploaded via HTTPS are sent over the Internet to the Section 111 COB Secure Website
(COBSW). This is done using the Section 111 COBSW application. There is no additional cost
or software associated with using this method as long as a standard Internet browser is used.
However, because this method requires a user to be logged in to the COBSW with an active
session, use of HTTPS is only recommended for entities with a relatively small amount of data to
submit (less than 24,000 records on a regular basis).
During account setup on the COBSW, your Account Manager can select this method for file
transfer. The account setup process is described in a previous section of the guide. The RRE’s
Account Manager obtains a COBSW Login ID and Password during the account setup process.
After that, the Account Manager can sign onto the COBSW and invite other users to obtain
Login IDs and be associated with the RRE’s account as Account Designees. All users associated
with the RRE’s account will have the ability to upload input files and download response files.
COBSW users associated with the RRE’s account will logon to the Section 111 application on
the COBSW at https://www.cob.cms.hhs.gov/Section111/ and use the application interface to
upload and download files. Instructions are provided in the Section 111 COBSW User Guide
available on the site and associated Help pages. Users must maintain an active session on the

8-5
GHP User Guide Chapter 8: Electronic Data Exchange

Section 111 application on the COBSW when uploading or downloading files via the HTTPS file
transfer method.
Note: When using the HTTPS file transmission method, only files with the file extension of .txt
are allowed for uploading. Any other file type will generate an Invalid File error message.
Files uploaded successfully to the COBSW are not subsequently accessible by users of the
COBSW. A user cannot not view or delete a file once uploaded. If a file is uploaded in error, you
should contact your EDI Representative for assistance.
Response files will remain available for downloading for two calendar quarters (180 days).
Response files can be downloaded more than once as needed. COBSW users cannot delete
response files from the COBSW. The BCRC will remove these files automatically after 60 days.
There is no specific naming convention needed when uploading input files.
The BCRC will name response files according to the following convention. A list of files
available for download will be presented to users of the COBSW when selecting the download
option in the Section 111 COBSW application.
MSP: PCOB.BA.MR.GHPMSP.RESP.Dccyymmdd.Thhmmssmm.TXT
TIN: PCOB.BA.MR.GHPTIN.RESP.Dccyymmdd.Thhmmssmm.TXT
Non-MSP: PCOB.BA.MR.GHPNMSP.RESP.Dccyymmdd.Thhmmssmm.TXT
Query: PCOB.BA.MR.GHPQRY.RESP.Dccyymmdd.Thhmmssmm.TXT
RDS: PCOB.BA.MR.GHPRDS.RESP.Dccyymmdd.Thhmmssmm.TXT
Unsolicited Resp: PCOB.BA.MR.GHPUNS.RESP.Dccyymmdd.Thhmmssmm.TXT
Where ‘Dccyymmdd’ is ‘D’ followed by a date as century/year/month/day and
‘Thhmmssmm’ is ‘T’ followed by a time as hours/minutes/seconds/centiseconds.
Files submitted via HTTPS to the COBSW should utilize an ASCII format. Fields within the
records are length delimited and all records are fixed length.

8-6
GHP User Guide Chapter 9: Querying for Medicare Coverage Information

Chapter 9: Querying for Medicare Coverage Information

In order to coordinate benefits and determine primary and secondary payers for health care
services, CMS will share Medicare coverage information for Medicare beneficiaries with Section
111 GHP responsible reporting entities. While you must report coverage information for all
Active Covered Individuals who are Medicare beneficiaries under Section 111, you may also be
interested to know the Medicare status for your other covered individuals. In most cases, when
an individual is currently employed (or is a dependent of a currently employed individual) but is
also covered by Medicare, your GHP coverage will be primary to Medicare. However, when the
subscriber retires, if the individual is covered by Medicare, then Medicare becomes the primary
payer. It is in our mutual best interest to have claims paid by the correct payer early rather than
later. To assist you, you may want to set up a process to query for Medicare coverage on each of
your retirees and/or their dependents until primary Medicare coverage is confirmed.
The distinction between an individual’s benefit eligibility and benefit enrollment can be
confusing. While it sometimes appears that the two terms are used interchangeably, for CMS
they have very different and distinct meanings.
Once an individual is a Medicare beneficiary, he or she is then eligible to participate in
Medicare’s benefit programs, including Part D. Usually, the Medicare beneficiary can choose to
participate, and if he or she does, the first day the beneficiary’s participation is effective is the
date of enrollment in the benefit program. For example, individuals who have aged into
Medicare Part A are then eligible to enroll in Medicare Parts B and D, if they so choose. Once an
application for enrollment is accepted, the beneficiary’s effective date of enrollment is
determined.
In summary, an eligible Medicare beneficiary may participate in Medicare program benefits
beginning on his or her date of enrollment in the benefit program. For beneficiaries who choose
to participate in the Part B and D programs, the date of enrollment is, usually, the first day of the
following month.

9.1 How to Obtain Medicare Coverage Information

9.1.1 File Transmission
If you report for Section 111 under the Basic Reporting Option, you will receive Medicare Parts
A, B, and C coverage information back on your MSP Response File for Active Covered
Individuals and Query Only Response File for Active and Inactive Covered Individuals. You will
also receive Part D eligibility information back on the MSP Response File for Active Covered
Individuals. If you report Medicare Part D primary prescription drug coverage, you will also
receive Medicare Part D enrollment information as of July 2019.
If you report for Section 111 under the Expanded Reporting Option, you will receive Medicare
Parts A, B, C and D coverage information back on your MSP Response File for Active Covered
Individuals and Non-MSP Response File for Inactive Covered Individuals. Expanded reporters
may also submit the Query Only File to get Part A, B and C coverage information back on any
covered individual, but Part D data is not yet available on this file layout. Part D coverage

9-1
GHP User Guide Chapter 9: Querying for Medicare Coverage Information

information will be added to the Query Only Response File for Expanded reporters at a later
date.
Please refer to the response file layouts in the appendices for the complete set of fields returned
with each response file.

9.1.2 Beneficiary Lookup on the Section 111 COBSW

When a Section 111 responsible reporting entity has an immediate need to access Medicare
entitlement information, the Beneficiary Lookup feature on the Section 111 COBSW permits
you to make a limited number of on-line queries to CMS to find out if an individual is eligible
for or enrolled in Medicare.
GHP RREs that are in a production status will have the Beneficiary Lookup action available on
the RRE Listing page after logging on to the Section 111 COBSW
(https://www.cob.cms.hhs.gov/Section111/). Refer to Section 7.1.6 and Chapter 11 for
information on how to obtain a Section 111 COBSW Login ID. The Beneficiary Lookup will
utilize the same matching criteria and methodology as used for the Query Only Input File and the
MSP Input File.
To use the Beneficiary Lookup action:
• Log on to the Section 111 COBSW
• The RRE Listing page will display
• Click on the Actions drop-down box for the RRE ID under which you wish to query
• Select the Beneficiary Lookup action from the list and click on the Go button
• The Beneficiary Lookup page will display
• On the Beneficiary Lookup page, enter the following required information
• Medicare ID (HICN or MBI) or SSN
Note: The Medicare ID is also known as the Medicare Number to CMS’ Medicare
beneficiaries.
• Covered Individual First Name
• Covered Individual Last Name
• Covered Individual Date of Birth
• Covered Individual Gender
• Click on the Next button.
• The system will attempt to match the information submitted to a Medicare beneficiary
• If a match is found, the Beneficiary Lookup Response page will display with Medicare
entitlement and enrollment information.
• If the information entered cannot be matched to a Medicare beneficiary, the Beneficiary
Not Found page will display.

9-2
GHP User Guide Chapter 9: Querying for Medicare Coverage Information

Important Considerations:
• RREs are limited to 500 query requests per RRE ID per calendar month using the
Beneficiary Lookup on the COBSW. Each month the system will display a count of the
remaining queries left and will reset this count up to 500 on the first day of each
succeeding calendar month. Each query submitted using the Beneficiary Lookup will
count toward this limit of 500 per month, regardless of whether or not a match was found.
• Use of the Beneficiary Lookup action is limited to the purposes prescribed by the Section
111 Data Use Agreement as documented in Chapter 10 of this guide and agreed to by the
RRE’s Authorized Representative on the signed Profile Report as well as by each user of
the Section 111 COBSW.
• The Beneficiary Lookup action will only be available for RRE IDs in a production status.
• All users associated to the RRE ID (Account Manager and Account Designees) will be
able to use the Beneficiary Lookup function.
• Use of the Beneficiary Lookup action is optional. It will be offered under all GHP RRE
IDs. No special application or sign-up is required.
• RREs using the Beneficiary Lookup action may continue to submit the Query-Only Input
File, as documented in the user guide. If you selected the Basic Reporting Option for
Section 111, you will be provided with Medicare Parts A, B, and C coverage information
and Part D eligibility dates. If you report primary prescription drug coverage, you will
also receive Part D coverage information as of July 2019. Expanded Reporting Option
submitters will continue to receive Parts A, B, C, and D coverage information.

9-3
GHP User Guide Chapter 10: Data Use Agreement

Chapter 10: Data Use Agreement

As part of the Section 111 registration process, the Authorized Representative for each Section
111 RRE will be asked to sign a copy of the following Data Use Agreement. It will be included
on the profile report sent to the Authorized Representative after Section 111 COBSW
registration and account setup. The Authorized Representative must sign and return the last page
of the profile report to the BCRC. In addition, all users must agree to similar language each time
they log on to the Section 111 application of the COBSW. Data exchanged for Section 111 is to
be used solely for the purposes of coordinating health care benefits for Medicare beneficiaries
between Medicare and Section 111 RREs who provide other health insurance coverage.
Measures must be taken by all involved parties to secure all data exchanged and ensure it is used
properly.
SAFEGUARDING & LIMITING ACCESS TO EXCHANGED DATA
I, the undersigned Authorized Representative of the Responsible Reporting Entity (RRE) defined
above, certify that the information contained in this Registration is true, accurate and complete
to the best of my knowledge and belief, and I authorize CMS to verify this information. I agree to
establish and implement proper safeguards against unauthorized use and disclosure of the data
exchanged for the purposes of complying with the Medicare Secondary Payer Mandatory
Reporting Provisions in Section 111 of the Medicare, Medicaid and SCHIP Extension Act
(MMSEA) of 2007. Proper safeguards shall include the adoption of policies and procedures to
ensure that the data obtained shall be used solely in accordance with Section 1106 of the Social
Security Act [42 U.S.C. § 1306], Section 1874(b) of the Social Security Act [42 U.S.C. §
1395kk(b)], Section 1862(b) of the Social Security Act [42 U.S.C. § 1395y(b)], and the Privacy
Act of 1974, as amended [5 U.S.C. § 552a]. The Responsible Reporting Entity and its duly
authorized agent for this Section 111 reporting, if any, shall establish appropriate
administrative, technical, procedural, and physical safeguards to protect the confidentiality of
the data and to prevent unauthorized access to the data provided by CMS. I agree that the only
entities authorized to have access to the data are CMS, the RRE or its authorized agent for
Mandatory Reporting. RREs must ensure that agents reporting on behalf of multiple RREs will
segregate data reported on behalf of each unique RRE to limit access to only the RRE and CMS
and the agent. Further, RREs must ensure that access by the agent is limited to instances where
it is acting solely on behalf of the unique RRE on whose behalf the data was obtained. I agree
that the authorized representatives of CMS shall be granted access to premises where the
Medicare data is being kept for the purpose of inspecting security arrangements confirming
whether the RRE and its duly authorized agent, if any, is in compliance with the security
requirements specified above. Access to the records matched and to any records created by the
matching process shall be restricted to authorized CMS and RRE employees, agents and officials
who require access to perform their official duties in accordance with the uses of the information
as authorized under Section 111 of the MMSEA of 2007. Such personnel shall be advised of (1)
the confidential nature of the information; (2) safeguards required to protect the information,
and (3) the administrative, civil and criminal penalties for noncompliance contained in
applicable Federal laws.

10-1
GHP User Guide Chapter 11: Section 111 COB Secure Web Site (COBSW)

Chapter 11: Section 111 COB Secure Website (COBSW)

The BCRC maintains an application on the Section 111 COB Secure Website (COBSW) to
support Section 111 reporting. All Section 111 GHP RREs must register and set up accounts on
the Section 111 COBSW. The COBSW URL is https://www.cob.cms.hhs.gov/Section111/.
On the COBSW, Section 111 reporters are able to:
• Complete the registration and account setup process. All information is collected through
an interactive Web application.
• Obtain Login IDs and assign users for Section 111 COBSW accounts.
• Exchange files via HTTPS or SFTP directly with the BCRC.
• View and update Section 111 reporting account profile information such as contacts and
company information.
• View the status of current file processing such as when a file was marked as received and
whether a response file has been created.
• View statistics related to previous file submission and processing.
• View statistics related to compliance with Section 111 reporting requirements such as
whether files and records have been submitted on a timely basis.
• Utilize an online query function, the Beneficiary Lookup, to determine the Medicare
status of a covered individual.
Sources of Help Related to Using the Section 111 COBSW
To access the Section 111 COBSW, go to https://www.cob.cms.hhs.gov/Section111/ using your
Internet browser. Once you click on the “I Accept” link and accept the terms of the Login
Warning, the homepage will display.
Information on the New Registration, Account Setup, and other processes can be found under the
“How To” menu option at the top of the homepage. A Login ID is not needed to access this
menu option. Click on the menu option and a drop-down list will appear. Then click on the item
desired in the list.
All pages of the Section 111 COBSW application provide access to “Quick Help” information.
Click on the link for Quick Help and a new window will open with instructions and information
needed to complete the page you are working on.
Once you have obtained a Login ID for the Section 111 COBSW, you may log into the
application using the Login fields displayed on the right side of the homepage. After login, a
detailed Section 111 COBSW User Guide is available under the “Reference Materials” menu
option at the top of the page. You must be logged into the application to gain access to the
COBSW User Guide.
Computer-Based Training (CBT) modules for the Section 111 application on the COBSW are
available free of charge to RREs and their agents. See Chapter 13 for information on how to
register for the CBT courses.

11-1
GHP User Guide Chapter 11: Section 111 COB Secure Web Site (COBSW)

Login IDs
Each person using the Section 111 COBSW must obtain their own Login ID and password. Your
personal Login ID may be used for access to multiple RRE IDs. Your Login ID will also be used
to transmit files via STFP (see Chapter 8). You can play one of two roles under an RRE ID with
your single Login ID - Account Manager or Account Designee. Authorized Representatives
cannot be users of the COBSW (See Section 7.1.6.2).
To obtain a Login ID, you must either perform the Account Setup step of the registration process
for the RRE ID on the COBSW and become the Account Manager or be invited by an already
established Account Manager to be associated to the RRE ID as an Account Designee. Refer to
the information in Section 7.1.6 on the registration process and the “How Tos” referenced above
for more information on obtaining Login IDs during the registration process.
If your organization has completed the registration process and you need a Login ID for the
COBSW, contact your Account Manager and request that he or she add you as an Account
Designee. You will receive an email invitation to come to the site and set up your Login ID and
password. Likewise, if you are a reporting agent and need access to a customer’s COBSW
account to assist with the reporting process, contact the RRE’s Account Manager to be invited as
an Account Designee.
Each RRE must assign or name an Account Manager. The Account Manager may be an
employee of the RRE or a reporting agent. Each RRE ID can have only one Account Manager.
This is the individual who controls the administration of an RRE’s account and manages the
overall reporting process. The Account Manager may choose to manage the entire account and
data file exchange or may invite other company employees or data processing agents to assist.
The Account Manager:
• Must register on the COBSW using the PIN for the RRE ID (See Section 7.1.6.2), obtain
a Login ID and complete the account setup tasks.
• Can be an Account Manager associated with another RRE ID if they receive the
authorized PIN from the BCRC mailing. This can occur when a reporting entity has
multiple RRE IDs under which they will report separate MSP Input Files or when the
entity chooses to name an agent as its Account Manager.
• Can invite other users to register on the COBSW as Account Designees for an RRE ID.
• Can manage the RRE’s profile including selection of a file transfer method.
• Can upload and download files to the COBSW if the RRE has specified HTTPS as the
file transfer method.
• Can use his or her Login ID and Password to transmit files if the RRE has specified SFTP
as the file transfer method.
• Can review file transmission history.
• Can review file-processing status and file statistics.
• Can remove an Account Designee’s association to an RRE ID account.
• Can change account contact information (e.g. address, phone, etc.)
• Can change his or her personal information.
• Cannot be an Authorized Representative for any RRE ID.
At the RRE’s discretion, the Account Manager may designate other individuals, known as
Account Designees, to register as users of the COBSW associated with the RRE’s account.
11-2
GHP User Guide Chapter 11: Section 111 COB Secure Web Site (COBSW)

Account Designees assist the Account Manager with the reporting process. Account Designees
may be RRE employees or agents.
The Account Designee:
• Must register on the COBSW and obtain a Login ID.
• Can be associated with multiple RRE accounts, but only by an Account Manager
invitation for each RRE ID.
• Can upload and download files to the COBSW if the RRE has specified HTTPS as the
file transfer method.
• Can use his or her Login ID and Password to transmit files if the RRE has specified SFTP
as the file transfer method.
• Can review file transmission history.
• Can review file-processing statuses and file statistics.
• Can change his or her personal information.
• Cannot be an Authorized Representative for any RRE ID.
• Cannot invite other users to the account.
• Cannot update RRE account information.
Note: Each user of the Section 111 application on the COBSW will have only one Login ID and
password. With that Login ID and password, you may be associated with multiple RRE IDs
(RRE accounts). With one Login ID, you may be an Account Manager for one RRE ID and an
Account Designee for another. In other words, the role you play on the COBSW is by RRE ID.
System-Generated Emails
Table 11-1 lists the emails that are generated by the system to the Authorized Representative,
Account Manager, and/or Account Designees for the RRE ID. Emails will be sent from
[email protected]. Please do not reply to this email address as replies are not monitored
by the BCRC. If additional information or action is needed, please contact your EDI
Representative directly.

Table 11-1: System-Generated Emails

Email Notification Recipient Purpose
Profile Report Authorized Representative, Sent after Account Setup step is complete
Account Manager on the COBSW. Includes attachment with
profile report. The profile report must be
signed by the RRE’s Authorized
Representative and returned to the BCRC.
Non-Receipt of Signed Authorized Representative, Generated 30 days after the Profile Report
Profile Report Account Manager email if a signed copy of the profile report
has not been received at the BCRC. The
Authorized Representative for the RRE ID
must sign and return the profile report. If
another copy is needed, contact your EDI
Representative.

11-3
GHP User Guide Chapter 11: Section 111 COB Secure Web Site (COBSW)

Email Notification Recipient Purpose

Successful File Receipt Account Manager Sent after an input file has been
successfully received but not yet processed
at the BCRC. Informational only. No
action required. Subsequent emails will be
sent regarding the results of actual file
processing.
Late File Submission Authorized Representative, Sent 7 days after the end of the file
Account Manager submission period if no MSP Input File
was received for the RRE ID. Send the file
immediately and contact your EDI
Representative.
Threshold Error Account Manager Sent when an input file has been
suspended for a threshold error. Contact
your EDI Representative to resolve.
Severe Error Account Manager Sent when an input file has been
suspended for a severe error. Contact your
EDI Representative to resolve.
Ready for Testing Account Manager Account setup is complete and the signed
profile report has been received at the
BCRC. The RRE may begin testing.
Non-Attainment of Authorized Representative, RRE ID has been in a testing status for
Production Status Account Manager more than 30 days. Informational only. Be
sure your EDI Representative is aware of
your testing progress.
Ready for Production Account Manager Testing requirements have been met and
production files will now be accepted for
the RRE ID.
Successful File Processed Account Manager The BCRC has completed processing on
an input file and the response file is
available.
Account Designee Invitation Account Designee Sent to an Account Designee after the
Account Manager for the RRE ID adds the
Account Designee to the RRE ID on the
COBSW. If the Account Designee is a
new user, the email will contain an URL
with a secure token link for the user to
follow to obtain a Login ID for the
COBSW.
Personal Information User Affected (Account Generated after a user changes his or her
Changed Manager or Account Designee) personal information on the COBSW.
Informational only.
Password Reset User Affected (Account Generated when a user’s password is reset
Manager or Account Designee) on the COBSW.
Login ID Request User Affected (Account Generated after a user completes the
Manager or Account Designee) “Forgot Login ID” function on the
COBSW.
Recertification of Profile Authorized Representative Generated annually on anniversary of
Report Information Account Manager upload of signed profile report or prior
recertification date.

11-4
GHP User Guide Chapter 11: Section 111 COB Secure Web Site (COBSW)

CMS advises all Section 111 COBSW users to implement the following best practices:
• Keep the personal computer Operating System and Internet Browser software (e.g.
Internet Explorer or Firefox) at the most current patch level.
• Install and use the latest versions of anti-virus/spyware software to continuously protect
personal computers.
• Use desktop firewall software on personal computers and ensure that file sharing is
disabled.
• Never use a public computer (library, internet café, etc.) to login to CMS resources.

11-5
GHP User Guide Chapter 12: Customer Service and Reporting Assistance

Chapter 12: Customer Service and Reporting Assistance

Please be sure to visit the Section 111 page on the CMS Website https://go.cms.gov/mirghp
frequently for updated information on Section 111 reporting requirements including updates to
this guide. In order to be notified via email of updates to these Web pages, please click the
Subscription Sign-up for Mandatory Insurer Reporting (GHP) Web Page Update Notification
link found in the Related Links section of the web page and add your email address to the
distribution list. When new information regarding mandatory insurer reporting for GHPs is
available, you will be notified.
The Section 111 Resource Mailbox, at [email protected], is a vehicle
that RREs may use to send CMS policy-related questions regarding the MSP reporting
requirements included in Section 111 of the Medicare, Medicaid, and SCHIP Extension Act of
2007 and the SUPPORT Act. You are requested to send only policy-related questions to the
Section 111 Resource Mailbox.
If you have a technical question, or if you are unable to contact your EDI Representative, for any
reason, call the EDI Hotline at (646) 458-6740.
Please note that emails from CMS or the BCRC may come from @cms.hhs.gov,
@ghimedicare.com and @ehmedicare.com addresses. Please update your spam filter software to
allow receipt of these email addresses.

12.1 EDI Representative

After you register for Section 111 reporting, you will be assigned an EDI Representative to be
your main contact for Section 111 file transmission and technical reporting issues. Contact
information for your EDI Representative will be provided on your profile report.
If you have not registered to become an RRE, or have not been assigned an EDI Representative,
please contact the BCRC directly at 1-855-798-2627.

12.2 Contact Protocol for the Section 111 Data Exchange

In all complex electronic data management programs, there is the potential for an occasional
breakdown in information exchange. If you have a program or technical problem involving
your Section 111 data exchange, the first person to contact is your own EDI Representative
at the BCRC. Your EDI Representative should always be sought out first to help you find
solutions for any questions, issues or problems you have.
If you have not yet been assigned an EDI Representative, please call the EDI Department at 646-
458-6740 for assistance.
Escalation Process
The BCRC places great importance in providing exceptional service to its customers. To that
end, we have developed the following escalation process to ensure our customers’ needs are
met:

12-1
GHP User Guide Chapter 12: Customer Service and Reporting Assistance

• If your Section 111 EDI Representative does not respond to your inquiry or issue within
two business days, you may contact the EDI Director, Angel Pagan, at 646-458-2121.
Mr. Pagan’s email is [email protected].
• If the EDI Director does not respond to your inquiry or issue within one business day,
you may contact the BCRC Project Director, Jim Brady, who has overall responsibility
for the EDI Department and technical aspects of the Section 111 reporting process. Mr.
Brady can be reached at 646-458-6682. His email address is [email protected].
Please contact Mr. Brady only after attempting to resolve your issue following the
escalation protocol provided above.

12-2
GHP User Guide Chapter 13: Training and Education

Chapter 13: Training and Education

Various forms of training and educational materials are available to help you with Section 111 in
addition to this guide.
• The GHP Section 111 CMS Web page at https://go.cms.gov/mirghp contains links to all
CMS publications regarding the MSP Mandatory Reporting Requirements under Section
111 of the MMSEA of 2007 for GHPs. In order to be notified via email of updates to
these pages, please click the Subscription Sign-up for Mandatory Insurer Reporting
(GHP) Web Page Update Notification link found in the Related Links section of the
web page and add your email address to the distribution list. When new information
regarding mandatory insurer reporting for GHPs is available, you will be notified.
• During implementation of the Section 111 reporting, CMS is conducting a series of
teleconferences to provide information regarding Section 111 reporting requirements.
The schedule for these calls is posted (and updated as new calls are scheduled) on the
GHP Alerts page of the CMS website at https://go.cms.gov/mirghp.
• CMS has made available a curriculum of computer-based training (CBT) courses to
Section 111 GHP RREs and agents. These courses provide in-depth training on Section
111 reporting requirements, file transmission, file formats, file processing, the Section
111 COBSW, and general MSP topics. These courses are all available on the GHP
Training Material page of the CMS website at
https://www.cms.gov/Medicare/Coordination-of-Benefits-and-Recovery/Mandatory-
Insurer-Reporting-For-Group-Health-Plans/GHP-Training-Material/GHP-Training-
Material-.html.
Note: The Section 111 User Guides and instructions do not and are not intended to cover all
aspects of the MSP program. Although these materials may provide high level overviews of
MSP in general, any individual/entity which has responsibility as a primary payer to Medicare is
responsible for their obligations under the law. The statutory provisions for MSP can be found at
42 U.S.C. 1395y(b); the applicable regulations can be found at 42 C.F.R. Part 411. Supplemental
guidance regarding the MSP provisions can also be found at:
• https://www.cms.gov/Medicare/Coordination-of-Benefits-and-Recovery/Coordination-of-
Benefits-and-Recovery-Overview/Medicare-Secondary-Payer/Medicare-Secondary-
Payer.html and
• https://www.cms.gov/Regulations-and-Guidance/Guidance/Manuals/Internet-Only-
Manuals-IOMs.html. The MSP manual is publication 100-05.

13-1
GHP User Guide Appendix A: MSP File Specifications

Appendix A MSP File Specifications

Section 111 GHP MSP Input File
MSP Input File Header Record

Table A-1: Section 111 GHP MSP Input File Header – 425 bytes
Field Name Size Displacement Data Type Description
1. Header 2 1-2 Alpha- Must be: ‘H0’
Indicator numeric
2. Section 111 9 3-11 Numeric ‘000000001’, ‘000000002’, etc. ID
RRE ID number assigned by the BCRC.
Required.
3. File Type 4 12-15 Alpha Must be ‘MSPI’ – MSP Input File.
4. File Date 8 16-23 Numeric Date CCYYMMDD
Required.
5. Filler 402 24-425 Alpha- Unused Field – fill with spaces.
Numeric

A-1
GHP User Guide Appendix A: MSP File Specifications

MSP Input File Detail Record

Table A-2: Section 111 GHP MSP Input File Detail Record - 425 bytes
Field Name Size Displacement Data Type Description
1. Medicare ID 12 1-12 Alpha-Numeric Active Covered
Individual’s/Beneficiary’s
Medicare ID (Health Insurance
Claim Number [HICN] or
Medicare Beneficiary Identifier
[MBI]).
Note: This is also known as the
Medicare Number to CMS’
Medicare beneficiaries.
Required if SSN not provided.
Required if the Active Covered
Individual is under 45 years of
age and is eligible for
Medicare due to ESRD or a
disability.
Populate with spaces if
unavailable.
2. Beneficiary 6 13-18 Text Active Covered
Surname Individual’s/Beneficiary’s Last
Name – Required.
Report the last name as it
appears on the individual’s SSN
or Medicare Card.
3. Beneficiary 1 19-19 Text Beneficiary’s First Initial –
First Initial Required.
Report the initial as it appears on
the individual’s SSN or
Medicare Card.
4. Beneficiary 8 20-27 Date Beneficiary’s DOB
Date of Birth (CCYYMMDD) – Required.
5. Beneficiary 1 28-28 Numeric Beneficiary’s Sex – Required.
Sex Code Valid Values:
0 = Unknown
1 = Male
2 = Female
6. DCN 15 29-43 Text Document Control Number;
assigned by the Section 111
GHP RRE.
Required. Each record within
the current file must have a
unique DCN.

A-2
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

7. Transaction 1 44-44 Numeric Type of Transaction –
Type Required.
Valid Values:
‘0’ = Add record
‘1’ = Delete record
‘2’ = Update/Change record
8. Coverage 1 45-45 Alpha-Numeric Type of Insurance – Required.
Type Valid Values:
‘J’ = Hospital Only
‘K’ = Medical Only
‘A’ = Hospital and Medical
‘U’ = Drug Only (network Rx)
‘V’ = Drug Only (non-network
Rx)
‘W’ = Comprehensive Coverage
–Hosp/Med/Drug (network Rx)
‘X’ = Hospital and Drug
(network Rx)
‘Y’ = Medical and Drug
(network Rx)
‘Z’ = Prescription Drug Health
Reimbursement Account (non-
network Rx)
‘4’ = Comprehensive Coverage
–Hosp/Med/Drug (non-network
Rx)
‘5’ = Hospital and Drug (non-
network Rx)
‘6’ = Medical and Drug (non-
network Rx)
‘R’ = Health Reimbursement
Arrangement (HRA)
9. Beneficiary 9 46-54 Alpha-numeric Active Covered
Social Security Individual’s/Beneficiary’s SSN
Number – Required if Medicare ID
(HICN or MBI) not provided.
Populate with 9 spaces or all
zeroes if unavailable.
10. Effective Date 8 55-62 Date Start Date of Covered
Individual’s GHP Coverage by
Insurer (CCYYMMDD).
Required.

A-3
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

11. Termination 8 63-70 Date End Date of Covered
Date Individual’s GHP Coverage.
(CCYYMMDD),
Note: Submit the last day that
the Active Covered Individual is
covered through a GHP due to
current employment status (with
the exception of situations
involving ESRD). Please see
Section 7.2.6.1. How to Report
a Coverage Termination Date
for Active Covered Individuals
for additional information and
examples. Required.
*Use all zeros if open-ended.
12. Relationship 2 71-72 Numeric Covered Individual’s
Code Relationship to Policy Holder –
Required.
Valid values:
‘01’ = Self; Covered Individual
is Policy Holder or Subscriber
‘02’ = Spouse or Common Law
Spouse
‘03’ = Child
‘20’ = Domestic Partner
‘04’ = Other Family Member
13. Policy 9 73-81 Text Employee or Subscriber’s First
Holder’s First name – Required.
Name
14. Policy 16 82-97 Text Employee or Subscriber’s Last
Holder’s Last Name – Required.
Name

A-4
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

15. Policy 9 98-106 Alpha-numeric Subscriber/Employee SSN
Holder’s SSN RREs must submit at least Field
15 – OR – the Individual Policy
Number (Field 18). Both fields
may be submitted, but RREs are
encouraged to use Field 18
instead of Field 15 if possible.
Field 18 should reflect the
unique identifier the RRE uses
for the individual being reported
on the record which in most
cases is the identification
number shown on the
individual’s insurance card. The
value supplied in these fields
will be placed on any related
recovery demand notifications
for the RRE to use to identify the
GHP coverage for the individual
reported on the record.
16. Employer Size 1 107 Numeric Valid Values:
‘0’ = 1 to 19 employees*
‘1’ = 20 to 99 employees*
‘2’ = 100 or more employees
*Employer Size Rule for Multi-
Employer Plans: If the employer
is part of a multi-employer plan,
this field should reflect the size
of the largest employer in the
plan. Enter ‘1’ if employer has
fewer than 20 full or part-time
employees but is part of a multi-
employer plan (a group of plans)
and another employer in that
group has 20 or more
employees.
Enter ‘2’ if employer has fewer
than 100 full or part-time
employees but is part of a multi-
employer plan where another
employer in that group has 100
or more employees.
Refer to 42 C.F.R. Part 411.101
and 42 C.F.R. Part 411.170 and
Appendix H for details on this
calculation.
Required.

A-5
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

17. Group Policy 20 108-127 Text Policy Number assigned by GHP
Number Payer.
If no group number exists, as in
the case of a self-insured RRE,
this field may be set to any valid
text value as a default.
For use when Coverage Type is
V, Z, 4, 5, and 6.
18. Individual 17 128-144 Text GHP’s unique individual
Policy Number identifier for the Active Covered
Individual (beneficiary) reported
on this record. Number that
appears on the individual’s
insurance card. It may reflect a
unique identifier used by the
RRE for the individual or the
subscriber/member/employee’s
unique identifier.
For self-insured RRE’s, covered
person’s member ID or other
unique ID used to identify
individuals covered by the plan.
The Policy Holder’s SSN
(Field 15) –OR - Individual
Policy Number (Field 18) is
required. Both fields may be
submitted, but RREs are
encouraged to use Field 18
instead of Field 15 if possible.
Field 18 should reflect the
unique identifier the RRE uses
for the individual being reported
on the record which in most
cases is the identification
number shown on the
individual’s insurance card. The
value supplied in these fields
will be placed on any related
recovery demand notifications
for the RRE to use to identify the
GHP coverage for the individual
reported on the record.
Always required for Coverage
Types V, Z, 4, 5, and 6.
Required when submitting a
record for the Small Employer
Exception (SEE).

A-6
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

19. Employee 1 145 Numeric Who the Policy Covers –
Coverage Optional.
Election ‘1’ = Policyholder/Subscriber
Only.
‘2’ = Policyholder/Subscriber &
Family (also use this value if the
coverage reflects
Policyholder/Subscriber &
Spouse only).
‘3’ = Policyholder/Subscriber &
Dependents, but not Spouse.
20. Employee 1 146 Numeric ‘1’ = Active/Currently
Status Employed during GHP effective
period reported.
‘2’ = Not Active/Not Currently
Employed during GHP effective
period reported.
Since only Active Covered
Individuals are to be submitted
on the MSP Input File, a value
of ‘2’ will only be used when
reporting individuals with ESRD
who are not covered due to
current employment status.
Otherwise, this indicator should
always be ‘1’. Refer to Section
7.1.2 of the User Guide that
defines Active Covered
Individuals.
Required.
21. Employer TIN 9 147-155 Numeric Employer Tax Identification
Number (EIN) – Required. A
matching record must be (or
have been) submitted on the TIN
Reference File.
For multiple employer/multi-
employer plans submit the plan
sponsor TIN rather than the
actual employer TIN.
22. Insurer/TPA 9 156-164 Numeric Insurer/TPA Tax Identification
TIN Number for the RRE –
Required. A matching record
must be (or have been)
submitted on the TIN Reference
File.
If the RRE is a TPA, report the
TIN of the TPA entity. If the
RRE is a self-insured
employer/plan sponsor entity,
then the TIN of the self-insured
employer/plan sponsor RRE is to
be used.

A-7
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

23. National 10 165-174 Filler National Health Plan Identifier –
Health Plan (Future Use). Fill with spaces.
24. Rx Insured ID 20 175-194 Text Insured’s Identification Number
Number for prescription drug coverage.
Required for Coverage Types
U, W, X, & Y.
Cannot be blank or all zeros
(effective 04/05/2021).
25. Rx Group 15 195-209 Text Group Number for prescription
Number drug coverage.
No longer required (effective
04/05/2021).
26. Rx PCN 10 210-219 Text Rx Processor Control Number.
Required if available.
Cannot have special
characters, except for a non-
leading dash, and no leading
space (effective 04/05/2021)
27. Rx BIN 6 220-225 Numeric Benefit Identification Number
Number for Rx processing.
Required for Coverage Types
U, W, X, & Y.
Must be a 6-digit number
Cannot be all the same
number (effective 04/05/2021).
28. Rx Toll Free 18 226- 243 Text plus “(“ and Prescription Drug/Pharmacy
Number “)” Benefit Information Toll Free
Number.
29. Person Code 3 244-246 Text Person Code the plan uses to
identify specific individuals on a
policy. The values are
established by the insurer. May
also known as a Dependent
Code.
30. Reserved 10 247-256 Alpha-Numeric Reserved for BCRC use.
Fill with spaces only.
31. Reserved 5 257-261 Alpha-Numeric Reserved for BCRC use.
Fill with spaces only.
32. Small 12 262-273 Alpha-Numeric Beneficiary’s Medicare ID
Employer (HICN or MBI) if exception has
Exception been approved for a small
Medicare ID employer.
Fill with spaces if there is no
approval.

A-8
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

33. Override Code 2 274-275 Alpha-Numeric Code used to override specific
hierarchy error codes. See
Section 7.2.8.
Valid Values:
HB = Hierarchy bypass. Use to
override error code SPH0.
Spaces = Not Applicable
34. Filler 150 276-425 Alpha-numeric Unused Field.
Fill with spaces only.

A-9
GHP User Guide Appendix A: MSP File Specifications

MSP Input File Trailer Record

Table A-3: Section 111 GHP MSP Input File Trailer Record - 425 bytes
Field Name Size Displacement Data Type Description
1. Trailer 2 1-2 Alpha- Must be: ‘T0’
Indicator Numeric
2. Section 111 9 3-11 Numeric ‘000000001’, ‘000000002’, etc. ID
RRE ID number assigned by the BCRC.
Required.
3. File Type 4 12-15 Alpha Must be ‘MSPI’ – MSP Input File.
4. File Date 8 16-23 Numeric Date CCYYMMDD
Required.
5. Record Count 9 24-32 Numeric Number of Active Covered Individual
records in this file. Do not include the
Header and Trailer Records in this
Record Count.
Required.
6. Filler 393 33-425 Alpha- Unused Field – fill with spaces.
Numeric

A-10
GHP User Guide Appendix A: MSP File Specifications

Section 111 GHP MSP TIN Reference File

TIN Reference Input File Header Record

Table A-4: Section 111 GHP MSP TIN Reference Input File Header Record - 425 bytes
Field Name Size Displacement Data Type Description
1. Header 2 1-2 Alpha- Must be: ‘H0’
Indicator Numeric
2. Section 111 9 3-11 Numeric ‘000000001’, ‘000000002’, etc. ID
RRE ID number assigned by the BCRC.
Required.
3. File Type 4 12-15 Alpha Must be: ‘REFR’ – TIN Reference
File.
Required.
4. File Date 8 16-23 Numeric Date CCYYMMDD
Required.
5. Filler 402 24-425 Alpha Unused Field – fill with spaces.
Numeric

A-11
GHP User Guide Appendix A: MSP File Specifications

TIN Reference Input File Detail Record

Table A-5: Section 111 GHP MSP TIN Reference Input File Detail Record - 425 bytes
Field Name Size Displacement Data Type Description
1. TIN 9 1-9 Numeric Tax identification number, EIN or
FEIN of the entity (insurer, TPA,
employer), or cross-reference
number to TIN field in the MSP
Input File Detail Records (Fields 21
and 22).
Must be unique – only one record
per TIN/TIN Indicator combination
will be processed and saved by the
BCRC. If multiple records for the
same TIN/TIN Indicator are
submitted on the TIN Reference
File, only the information for the
last record will be used.
Corresponds to either Field 21 or 22
of the MSP Input File Detail
Record.
Each TIN used in Fields 21 and 22
of MSP Input File Detail Records
must have a corresponding TIN
Reference File Detail Record.
The value in the TIN indicator
(Field 8) identifies what type of TIN
is being submitted on this record.
Required.
2. Name 32 10-41 Text Name of the entity.
Will be used with the Mailing
Address Fields 3-7.
Required.

A-12
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

3. Address Line 32 42-73 Text Address Line 1.
1 The mailing address associated with
each TIN should be the address to
which health care insurance
coordination of benefits issues
should be directed. This mailing
address will help CMS and others to
direct correspondence to the most
appropriate contact at the GHP
responsible reporting entity,
employer, or plan sponsor.
Street number and street name
should be placed on one address line
field while other information such
as suite number, attention to, etc.
should be placed on the other.
If the TIN Indicator (Field 8) = ‘I’,
then this address may be used by
providers and suppliers to redirect
claim submissions.
If the TIN Indicator (Field 8) is ‘E’,
‘S’, or ‘Z’ reflecting an employer
TIN record, and no US address is
available, fill with spaces and put
‘FC’ in the State (Field 6) and
provide the Foreign Employer
Address starting in Field 15.
Required.
4. Address Line 32 74-105 Text Address Line 2.
2 If the TIN Indicator = ‘I’, then this
address may be used by providers
and suppliers to redirect claim
submissions.
If the TIN Indicator (Field 8) is ‘E’,
‘S’, or ‘Z’ reflecting an employer
TIN record, and no US address is
available, fill with spaces and put
‘FC’ in the State (Field 6) and
provide the Foreign Employer
Address starting in Field 15.

A-13
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

5. City 15 106-120 Text City.
If the TIN Indicator = ‘I’, then this
address may be used by providers
and suppliers to redirect claim
submissions.
If the TIN Indicator (Field 8) is ‘E’,
‘S’, or ‘Z’ reflecting an employer
TIN record, and no US address is
available, fill with spaces and put
‘FC’ in the State (Field 6) and
provide the Foreign Employer
Address starting in Field 15.
Required.
6. State 2 121-122 Alpha State – Must be a valid USPS state
abbreviation or ‘FC’. The value of
‘FC’ is effective with files
submitted April 1, 2010 and
subsequent. See
http://pe.usps.gov/text/pub28/28apb.
htm. If the TIN Indicator = ‘I’, then
this address may be used by
providers and suppliers to redirect
claim submissions.
If the TIN Indicator (Field 8) is ‘E’,
‘S’, or ‘Z’ reflecting an employer
TIN record, and no US address is
available, fill with ‘FC’ and provide
the Foreign Employer Address
starting in Field 15.
Required.
7. Zip Code 9 123-131 Alpha- Zip Code.
Numeric If the TIN Indicator = ‘I’, then this
address may be used by providers
and suppliers to redirect claim
submissions.
If the TIN Indicator (Field 8) is ‘E’,
‘S’, or ‘Z’ reflecting an employer
TIN record, and no US address is
available, fill with spaces and put
‘FC’ in the State (Field 6) and
provide the Foreign Employer
Address starting in Field 15.
First 5 positions required.

A-14
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

8. TIN Indicator 1 132 Alpha Used to indicate whether the TIN is
for an insurer/TPA or employer.
Values:
E = The TIN field contains a valid
TIN (EIN) for an Employer.
I = The TIN field contains a valid
TIN for an Insurer/TPA.
S = The TIN field contains a valid
TIN for the plan sponsor of a
multiple employer/multi-employer
plan.
F = The TIN field contains a valid
TIN for a Federal employer.
Z = The TIN field reflects a foreign
employer that has no valid TIN. The
TIN field contains a pseudo-TIN for
the foreign employer.
Required.
9. Insurer/TPA 32 133-164 Text Name to be used on insurer/TPA’s
Demand courtesy copy of demand packages
Mailing sent for recovery purposes if
Name different from where claims should
be forwarded. If not supplied then
Fields 2-7 will be used on recovery
demand packages.
Use only if TIN Indicator (Field 8)
= ‘I’.
The Demand Name and Address
fields are optional but if any are
supplied, then Demand Name,
Demand Address Line 1, Demand
City, Demand State and Demand
Zip are required.
Optional.
10. Insurer/TPA 32 165-196 Text Address line 1 to be used on
Demand insurer/TPA’s courtesy copy of
Address Line demand packages sent for recovery
1 purposes if different from where
claims should be forwarded. If not
supplied then Fields 2-7 will be
used on demand packages.
Street number and street name
should be placed on one address line
field while other information such
as suite number, attention to, etc.
should be placed on the other.
Use only if TIN Indicator (Field 8)
= ‘I’.
Optional.

A-15
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

11. Insurer/TPA 32 197-228 Text Address line 2 to be used on
Demand insurer/TPA’s courtesy copy of
Address Line demand packages sent for recovery
2 purposes if different from where
claims should be forwarded. If not
supplied then Fields 2-7 will be
used on demand packages.
Use only if TIN Indicator (Field 8)
= ‘I’.
Optional.
12. Insurer/TPA 15 229-243 Text City to be used on insurer/TPA’s
Demand courtesy copy of demand packages
Mailing City sent for recovery purposes if
different from where claims should
be forwarded. If not supplied then
Fields 2-7 will be used on demand
packages.
Use only if TIN Indicator (Field 8)
= ‘I’.
Optional.
13. Insurer/TPA 2 244-245 Alpha State to be used on insurer/TPA’s
Demand courtesy copy of demand packages
Mailing State sent for recovery purposes if
different from where claims should
be forwarded. If not supplied then
Fields 2-7 will be used on demand
packages.
Use only if TIN Indicator (Field 8)
= ‘I’.
Optional.
14. Insurer/TPA 9 246-254 Alpha- USPS Zip Code to be used on
Demand numeric insurer/TPA’s courtesy copy of
Mailing Zip demand packages sent for recovery
purposes if different from where
claims should be forwarded. If not
supplied then Fields 2-7 will be
used on demand packages.
Use only if TIN Indicator (Field 8)
= ‘I’.
Optional.
15. Foreign 32 255-286 Text First line of mailing address of a
Employer foreign employer.
Address Line Use only if TIN Indicator (Field 8)
1 = ‘E’, ‘S’, or ‘Z’ and employer has
no US address.
Required if State (Field 6) = ‘FC’.

A-16
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

16. Foreign 32 287-318 Text Second line of mailing address of a
Employer foreign employer.
Address Line Use only if TIN Indicator (Field 8)
2 = ‘E’, ‘S’, or ‘Z’ and employer has
no US address.
Optional.
17. Foreign 32 319-350 Text Third line of mailing address of a
Employer foreign employer.
Address Line Use only if TIN Indicator (Field 8)
3 = ‘E’, ‘S’, or ‘Z’ and employer has
no US address.
Optional.
18. Foreign 32 351-382 Text Fourth line of mailing address of a
Employer foreign employer.
Address Line Use only if TIN Indicator (Field 8)
4 = ‘E’, ‘S’, or ‘Z’ and employer has
no US address.
Optional.
19. Filler 43 383-425 Text Future use – Fill with spaces.

A-17
GHP User Guide Appendix A: MSP File Specifications

TIN Reference Input File Trailer Record

Table A-6: Section 111 GHP MSP TIN Reference Input File Trailer Record - 425 bytes
Field Name Size Displacement Data Type Description
1. Trailer 2 1-2 Alpha- Must be: ‘T0’
Indicator Numeric
2. Section 111 9 3-11 Numeric ‘000000001’, ‘000000002’, etc. ID
RRE ID number assigned by the BCRC.
Required.
3. File Type 4 12-15 Alpha Must be: ‘REFR’ – TIN Reference
File.
4. File Date 8 16-23 Numeric Date CCYYMMDD
Required.
5. Record Count 9 24-32 Numeric Number of TIN records in this file. Do
not include the Header and Trailer
Records in the Record Count.
Required.
6. Filler 393 33-425 Alpha- Unused Field – fill with spaces.
Numeric

A-18
GHP User Guide Appendix A: MSP File Specifications

Section 111 GHP MSP Response File

MSP Response File Header Record

Table A-7: Section 111 GHP MSP Response File Header Record - 800 bytes
Field Name Size Displacement Data Type Description
1. Header 2 1-2 Alphanumeric Must be: ‘H0’
Indicator
2. Section 9 3-11 Numeric ‘000000001’, ‘000000002’,
111 RRE etc. ID number assigned by the
ID BCRC.
Corresponds to the RRE ID
submitted on the MSP Input
File.
3. File Type 4 12-15 Alpha ‘MSPR’ – MSP Response
File.
4. File Date 8 16-23 Numeric Date CCYYMMDD
BCRC supplied.
5. Filler 777 24-800 Alphanumeric Unused Field. Space filled.

A-19
GHP User Guide Appendix A: MSP File Specifications

MSP Response File Detail Record

Table A-8: Section 111 GHP MSP Response File Detail Record - 800 bytes
Field Name Size Displacement Data Type Description
1. Filler 4 1-4 Alphanumeric For BCRC internal use.
2. Medicare ID 12 5-16 Alphanumeric Medicare ID (Health Insurance
Claim Number [HICN] or
Medicare Beneficiary
Identifier [MBI])
If the information submitted
on the input record was
matched to a Medicare
beneficiary, this field will
contain the most current
Medicare ID for the
beneficiary.
Note: This is also known as
the Medicare Number to CMS’
Medicare beneficiaries.
Store this Medicare ID in your
system for future updates and
deletes.
3. Beneficiary 6 17-22 Text Beneficiary’s Last Name.
Surname Field will contain either the
first 6 characters of the name
supplied or the corrected
name from BCRC database.
4. Beneficiary 1 23 Text Beneficiary’s First Initial.
First Initial Field will contain either the
value supplied or the
corrected value from BCRC
database.
5. Beneficiary 8 24-31 Numeric Date Beneficiary’s DOB
Date of Birth (CCYYMMDD).
Field will contain either the
value supplied or the
corrected value from BCRC
database.
6. Beneficiary Sex 1 32 Alphanumeric Beneficiary’s Sex:
Code 0 = Unknown
1 = Male
2 = Female
Field will contain either the
value supplied or the
corrected value from BCRC
database.
7. BCRC DCN 15 33-47 Alphanumeric Document Control Number
assigned by the BCRC.
BCRC supplied.

A-20
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

8. Disposition 2 48-49 Alphanumeric Response Disposition Code
Code from BCRC (via the Medicare
CWF).
See GHP Disposition Code
Table for values.
9. Transaction 1 50 Alphanumeric Type of Transaction:
Type ‘0’ = Add Record
‘1’ = Delete record
‘2’ = Update record
Transaction Type applied by
BCRC.
10. Reason for 1 51 Alphanumeric Reason for Medicare
Medicare Entitlement:
Entitlement ‘A’ = Aged
‘B’ = ESRD
‘G’ = Disabled
Value returned if individual is
entitled.
BCRC supplied.
11. Coverage Type 1 52 Alphanumeric Type of Insurance:
(insurer Valid Values:
type/policy ‘J’ = Hospital Only
type)
‘K’ = Medical Only
‘A’ = Hospital and Medical
‘U’ = Drug Only (network Rx)
‘V’ = Drug Only (non-network
Rx)
‘W’ = Comprehensive
Coverage –Hosp/Med/Drug
(network Rx)
‘X’ = Hospital and Drug
(network Rx)
‘Y’ = Medical and Drug
(network Rx)
‘Z’ = Prescription Drug Health
Reimbursement Account (non-
network Rx)
‘4’ = Comprehensive
Coverage –Hosp/Med/Drug
(non-network Rx)
‘5’ = Hospital and Drug (non-
network Rx)
‘6’ = Medical and Drug (non-
network Rx)
Field will contain value
supplied on input.
‘R’ = Health Reimbursement
Arrangement (HRA)

A-21
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

12. Insurer Name 32 53-84 Text Insurer name.
Field will contain value
supplied on TIN Reference
File.
13. Insurer Address 32 85-116 Text Insurer’s Address Line 1.
1 Field will contain value
supplied on TIN Reference
File.
14. Insurer Address 32 117-148 Text Insurer’s Address Line 2.
2 Field will contain value
supplied on TIN Reference
File.
15. Insurer City 15 149-163 Text Insurer’s City.
Field will contain value
supplied on TIN Reference
File.
16. Insurer State 2 164-165 Alpha Insurer’s State.
Field will contain value
supplied on TIN Reference
File.
17. Insurer Zip 9 166-174 Alphanumeric Insurer’s Zip Code.
Code Field will contain value
supplied on TIN Reference
File.
18. Beneficiary 9 175-183 Alphanumeric Beneficiary’s SSN.
SSN Field will contain the value
supplied by the RRE on the
input record.
19. MSP Effective 8 184-191 Numeric Date Start date of Beneficiary’s
Date Primary GHP Coverage
(CCYYMMDD). Effective
date of the MSP occurrence
posted on the Medicare CWF
or MBD.
Medicare is the secondary
payer between the MSP
Effective Date and MSP
Termination Date.
The MSP Effective Date is set
to the Medicare entitlement
date if that is later than the
submitted GHP coverage
Effective Date. Therefore, it
may be set to a future date
since Medicare
entitlement/enrollment
information is often
established in advance.
BCRC supplied.

A-22
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

20. MSP 8 192-199 Numeric Date End date of Beneficiary’s
Termination Primary GHP Coverage
Date (CCYYMMDD). End date of
the MSP occurrence posted on
the Medicare CWF or MBD.
*All zeros if open-ended.
Medicare is the secondary
payer between the MSP
Effective Date and MSP
Termination Date.
BCRC supplied.
21. Relationship 2 200-201 Alphanumeric Covered Individual’s
Code Relationship to Active
Employee:
‘01’ = Covered Individual is
Active Employee
‘02’ = Spouse or Common
Law Spouse
‘03’ = Child
‘20’ = Domestic Partner
‘04’ = Other Family Member
Default is ‘01’
22. Policy Holder’s 9 202-210 Text Active Employee’s First
First Name Name.
Field will contain value
supplied on input.
23. Policy Holder’s 16 211-226 Text Active Employee’s Last
Last Name Name.
Field will contain value
supplied on input.
24. Policy Holder’s 12 227-238 Alphanumeric Subscriber/Employee SSN.
SSN (9 digits, left justified.)
Field will contain value
supplied on input.
25. Employer’s 32 239-270 Text Employer Providing Coverage.
Name Field will contain the value
supplied on the TIN Reference
File.
26. Employer’s 32 271-302 Text Employer’s Street Address,
Address Line 1 line 1.
Field will contain value
supplied on TIN Reference
File.
27. Employer’s 32 303-334 Text Employer’s Street Address,
Address Line 2 line 2.
Field will contain value
supplied on TIN Reference
File.

A-23
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

28. Employer’s 15 335-349 Text Employer’s City.
City Field will contain value
supplied on TIN Reference
File.
29. Employer’s 2 350-351 Alpha Employer’s State Code.
State Field will contain value
supplied on TIN Reference
File.
30. Employer’s Zip 9 352-360 Alphanumeric Employer’s Zip Code.
Code Field will contain value
supplied on TIN Reference
File.
31. Group Policy 20 361-380 Text Group Policy Number.
Number Field will contain value
supplied on input.
32. Individual 17 381-397 Text Individual’s Policy Number.
Policy Number Field will contain value
supplied on input.
33. Last Query 8 398-405 Numeric Date Last Date the BCRC sent a
Date record for this MSP
occurrence to the CWF
(Common Working File)
(CCYYMMDD).
BCRC supplied.
34. Current 2 406-407 Alphanumeric Result from Most Current
Disposition CWF Transmission (same as
Code Field #8).
BCRC supplied.
35. Current 8 408-415 Numeric Date Date of Most Current CWF
Disposition Transmission
Date (CCYYMMDD).
BCRC supplied.
36. Previous 2 416-417 Alphanumeric Result from Previous CWF
Disposition Transmission.
Code BCRC supplied.
37. Previous 8 418-425 Numeric Date Date of Previous CWF
Disposition Transmission
Date (CCYYMMDD).
BCRC supplied.
38. First 2 426-427 Alphanumeric Result from First CWF
Disposition Transmission.
Code BCRC supplied.
39. First 8 428-435 Numeric Date Date of First CWF
Disposition Transmission
Date (CCYYMMDD).
BCRC supplied.

A-24
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

40. Error Code 1 4 436-439 Alphanumeric SP Error Code 1
See SP Error Code Table for
values.
BCRC or CWF supplied.
41. Error Code 2 4 440-443 Alphanumeric SP Error Code 2
See SP Error Code Table for
values.
BCRC or CWF supplied.
42. Error Code 3 4 444-447 Alphanumeric SP Error Code 3
See SP Error Code Table for
values.
BCRC or CWF supplied.
43. Error Code 4 4 448-451 Alphanumeric SP Error Code 4
See SP Error Code Table for
values.
BCRC or CWF supplied.
44. Split 1 452 Alpha Entitlement Split Indicator:
Entitlement ‘Y’ = yes
Indicator
‘N’ or blank = no
BCRC supplied.
45. Original 1 453 Alphanumeric Original Reason for Medicare
Reason for Entitlement:
Medicare ‘A’ = Aged
Entitlement
‘B’ = ESRD
‘G’ = Disabled
BCRC supplied.
46. Original 8 454-461 Numeric Date The original GHP coverage
Coverage effective date sent. This gets
Effective Date populated if a SP31 error
occurs (CCYYMMDD).
Field will be the value
supplied on input.
47. Original 8 462-469 Numeric Date The original GHP coverage
Coverage termination date sent. This gets
Termination populated if an SP32 error
Date* occurs (CCYYMMDD).
Field will be the value
supplied on input.
*All zeros if open-ended.

A-25
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

48. RRE Assigned 15 470-484 Text The Document Control
DCN Number assigned by the
Section 111 GHP responsible
reporting entity. It is moved
here so we can provide our
own unique BCRC DCN in
Field 7.
Field will be the value
supplied on input.
49. Current 8 485-492 Numeric Date Effective Date of Medicare
Medicare Part Part A Coverage
A Effective (CCYYMMDD).
Date BCRC supplied.
50. Current 8 493-500 Numeric Date Termination Date of Medicare
Medicare Part Part A Coverage
A Termination (CCYYMMDD).
Date* BCRC supplied.
* All zeros if open-ended.
51. Current 8 501-508 Numeric Date Effective Date of Medicare
Medicare Part Part B Coverage
B Effective (CCYYMMDD).
Date BCRC supplied.
52. Current 8 509-516 Numeric Date Termination Date of Medicare
Medicare Part Part B Coverage
B Termination (CCYYMMDD).
Date* BCRC supplied.
* All zeros if open-ended.
53. Medicare 8 517-524 Numeric Date Medicare Beneficiary Date of
Beneficiary Death (CCYYMMDD).
Date of Death BCRC supplied.
54. Current 5 525-529 Alphanumeric Contractor Number of the
Medicare Part current Medicare Part C Plan
C Plan in which the beneficiary is
Contractor enrolled.
Number BCRC supplied.
55. Current 8 530-537 Numeric Date Effective Date of coverage
Medicare Part provided by current Medicare
C Plan Part C Plan (CCYYMMDD).
Enrollment BCRC supplied.
Date
56. Current 8 538-545 Numeric Date Termination Date of coverage
Medicare Part provided by current Medicare
C Plan Part C Plan (CCYYMMDD).
Termination BCRC supplied.
Date*
* All zeros if open-ended (i.e.,
if coverage is not terminated).

A-26
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

57. Current 5 546-550 Alphanumeric Contractor Number of the
Medicare Part Medicare Part D Plan
D Plan BCRC supplied.
Contractor
Provided to Expanded and
Number
Basic reporters who indicate
they offer primary prescription
drug coverage on their S111
profile.
58. Current Part D 8 551-558 Numeric Date Effective Date of coverage
Plan provided by Medicare Part D
Enrollment Plan (CCYYMMDD).
Date BCRC supplied.
Provided to Expanded and
Basic reporters who indicate
they offer primary prescription
drug coverage on their S111
profile.
59. Current 8 559-566 Numeric Date Termination Date of coverage
Medicare Part Medicare Part D Plan
D Plan (CCYYMMDD).
Termination BCRC supplied.
Date*
* All zeros if open-ended (i.e.,
if coverage is not terminated).
Provided to Expanded and
Basic reporters who indicate
they offer primary prescription
drug coverage on their S111
profile.
60. Part D 8 567-574 Numeric Date Earliest date that Beneficiary
Eligibility Start is eligible to receive Part D
Date Benefits – Refer to Field 58
for Part D Plan Enrollment
Date (CCYYMMDD).
BCRC supplied.
61. Part D 8 575-582 Numeric Date Date the Beneficiary is no
Eligibility Stop longer eligible to receive Part
Date* D Benefits – Refer to Field 59
for Part D Plan Termination
Date (CCYYMMDD).
BCRC supplied.
* All zeros if open-ended.
62. National Health 10 583-592 Alphanumeric National Health Plan
Plan ID Identifier. (Future
requirement.)
Field will contain value
supplied on input.

A-27
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

63. Rx Insured ID 20 593-612 Text Insured’s Identification
number Number.
Field will contain value
supplied on input.
64. Rx Group 15 613-627 Text Group Number.
Number Field will contain value
supplied on input.
65. Rx PCN 10 628-637 Text Processor Control Number.
Field will contain value
supplied on input.
66. Rx BIN 6 638-643 Text Benefit Identification Number
Number for Rx processing.
Field will contain value
supplied on input.
67. Rx 800 Number 18 644-661 Text plus “(“ and Pharmacy benefit information
“)” Toll Free Number.
Field will contain value
supplied on input.
68. Person Code 3 662-664 Text Person Code.
Field will contain value
supplied on input.
69. Rx Disposition 2 665-666 Alphanumeric Response Rx Disposition Code
Code from BCRC Medicare
Beneficiary Database or MBD.
See GHP Disposition Code
Table for values.
Code supplied by the BCRC.
70. Rx Disposition 8 667-674 Numeric Date Date Rx Disposition Code was
Date generated
(CCYYMMDD).
Code supplied by the BCRC.
71. Rx Error Code 4 675-678 Alphanumeric Rx Error Code 1.
1 Refer to GHP Rx Error Codes
for values.
BCRC supplied.
72. Rx Error Code 4 679-682 Alphanumeric Rx Error Code 2.
2 Refer to GHP Rx Error Codes
for values.
BCRC supplied.
73. Rx Error Code 4 683-686 Alphanumeric Rx Error Code 3.
3 Refer to GHP Rx Error Codes
for values.
BCRC supplied.

A-28
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

74. Rx Error Code 4 687-690 Alphanumeric Rx Error Code 4.
4 Refer to GHP Rx Error Codes
for values.
BCRC supplied.
75. ESRD 8 691-698 Numeric Date The start date for the 30-month
Coordination coordination period in which
Period Start GHP coverage is considered
Date primary to Medicare because
the beneficiary has a diagnosis
of End Stage Renal Disease
(CCYYMMDD).
BCRC supplied.
76. ESRD 8 699-706 Numeric Date The ending date for the 30-
Coordination month coordination period in
Period End which GHP coverage is
Date considered primary to
Medicare because the
beneficiary has a diagnosis of
ESRD. A corresponding GHP
coverage will no longer be
considered an MSP record
after the 30-month
coordination period is
terminated (CCYYMMDD).
BCRC supplied.
77. First Dialysis 8 707-714 Numeric Date A date that indicates when the
Date ESRD Dialysis first started
(CCYYMMDD).
Value will be zero if not
applicable.
BCRC supplied.
78. ESRD Self- 8 715-722 Numeric Date A date that indicates when the
Training Date beneficiary participated in
ESRD Self - Care Training
(CCYYMMDD).
Value will be zero if not
applicable.
BCRC supplied.
79. Transplant Date 8 723-730 Numeric Date A date that indicates when a
– Most Recent Kidney Transplant Operation
occurred (CCYYMMDD).
Value will be zero if not
applicable.
BCRC supplied.
80. Transplant 8 731-738 Numeric Date A date that indicates when a
Failure Date – Kidney Transplant failed. Last
Most Recent occurrence will be reported
(CCYYMMDD).
BCRC supplied.

A-29
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

81. SEE Response 2 739-740 Alphanumeric Small Employer Exception
Code (SEE) Response Code.
(Spaces): Not applicable. SEE
Medicare ID not provided
SA – SEE Medicare ID
accepted
SN – SEE Medicare ID not
accepted
SP – SEE Medicare ID
partially accepted (SEE
Medicare ID period does not
cover entire MSP period)
BCRC supplied.
82. Late 1 741-741 Alphanumeric Value of ‘Y’ indicates that the
Submission submitted record was not
Indicator received timely. See Section
7.2.8.6.
BCRC supplied.
83. Compliance 2 742-743 Alphanumeric Future Use – not used at this
Flag 1 time.
Space filled.
84. Compliance 2 744-745 Alphanumeric Future Use – not used at this
Flag 2 time.
Space filled.
85. Compliance 2 746-747 Alphanumeric Future Use – not used at this
Flag 3 time.
Space filled.
86. Compliance 2 748-749 Alphanumeric Future Use – not used at this
Flag 4 time.
Space filled.
87. Compliance 2 750-751 Alphanumeric Future Use – not used at this
Flag 5 time.
Space filled.
88. Compliance 2 752-753 Alphanumeric Future Use – not used at this
Flag 6 time.
Space filled.
89. Compliance 2 754-755 Alphanumeric Future Use – not used at this
Flag 7 time.
Space filled.
90. Compliance 2 756-757 Alphanumeric Future Use – not used at this
Flag 8 time.
Space filled.
91. Compliance 2 758-759 Alphanumeric Future Use – not used at this
Flag 9 time.
Space filled.

A-30
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

92. Compliance 2 760-761 Alphanumeric Future Use – not used at this
Flag 10 time.
Space filled.
93. Filler 39 762-800 Alphanumeric Unused field. Space filled.

A-31
GHP User Guide Appendix A: MSP File Specifications

MSP Response File Trailer Record

Table A-9: Section 111 GHP MSP Response File Trailer Record - 800 bytes
Field Name Size Displacement Data Type Description
1. Trailer 2 1-2 Alphanumeric Will contain a value of ‘T0’.
Indicator BCRC supplied.
2. Section 9 3-11 Numeric ‘000000001’, ‘000000002’,
111 RRE etc. ID number assigned by
ID BCRC.
Corresponds to the RRE ID
submitted on the MSP Input
File.
BCRC supplied.
3. File Type 4 12-15 Alpha ‘MSPR’ – MSP Response
File.
BCRC supplied.
4. File Date 8 16-23 Numeric Date CCYYMMDD
BCRC supplied.
5. Record 9 24-32 Numeric Number of response records
Count contained in this file. Does not
include the header and trailer
records in the count.
BCRC supplied.
6. Filler 768 33-800 Alphanumeric Unused field. Space filled.

A-32
GHP User Guide Appendix A: MSP File Specifications

Section 111 GHP TIN Reference Response File

TIN Reference Response File Header Record

Table A-10: Section 111 GHP MSP TIN Reference Response File Header Record - 650
bytes
Field Name Size Displacement Data Type Description
1. Header 2 1-2 Alphanumeric Contains a value of ‘H0’
Indicator
2. Section 9 3-11 Numeric ID number assigned by the
111 RRE BCRC.
ID
3. File Type 4 12-15 Alpha ‘TGRP’ – TIN Reference
Response File.
4. File Date 8 16-23 Numeric Date CCYYMMDD
5. Filler 627 24-650 Alphanumeric Filled with spaces.

A-33
GHP User Guide Appendix A: MSP File Specifications

TIN Reference Response File Detail Record

Table A-11: Section 111 GHP MSP TIN Reference Response File Detail Record - 650 bytes
Field Name Size Displacement Data Type Description
1. Submitted 9 1-9 Numeric Submitted tax identification
TIN number of the entity.
2. Submitted 32 10-41 Text Submitted name of the entity.
Name This field (and others that follow)
will contain the submitted
Insurer/TPA information if TIN
indicator equals I. It will contain
Employer information if TIN
indicator equals E, S, F or Z.
3. Submitted 32 42-73 Text Submitted Address Line 1 as
Address Line provided on input record.
1
4. Submitted 32 74-105 Text Submitted Address Line 2 as
Address Line provided on input record.
2
5. Submitted 15 106-120 Text Submitted City as provided on
City input record.
6. Submitted 2 121-122 Alpha Submitted State as provided on
State input record.
7. Submitted Zip 9 123-131 Alpha-Numeric Submitted ZIP Code as provided
Code on input record.
8. Applied 32 132-163 Text Address Line 1, after address
Address 1 validation completed, which will
be used by Medicare for
subsequent processing. Mailing
Address Change Flag (Field 40)
will equal Y if the applied address
in Fields 8 – 12 is different from
the submitted address (Fields 3-7)
and N if it is the same as the
submitted address. Will contain
spaces if the TIN record was
rejected. The field will also
contain spaces if the submitted
State code contained ‘FC’
indicating the address is foreign.
9. Applied 32 164-195 Text Address Line 2 after address
Address 2 validation completed. See
description for Field 8.
10. Applied City 13 196-208 Text City after address validation
completed. See description for
Field 8.
11. Applied State 2 209-210 Alpha State after address validation
completed. See description for
Field 8.

A-34
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

12. Applied Zip 9 211-219 Alpha-numeric Zip Code after address validation
Code completed. See description for
Field 8.
13 Submitted 1 220-220 Alpha Submitted TIN Indicator as
TIN Indicator provided on the input record.
14. Submitted 32 221-252 Text Insurer/TPA Demand Mailing
Insurer/TPA Name as provided on the input
Demand record.
Mailing Name
15. Submitted 32 253-284 Text Insurer/TPA Demand Address
Insurer/TPA Line 1 as provided on input
Demand record.
Address Line
1
16. Submitted 32 285-316 Text Insurer/TPA Demand Address
Insurer/TPA Line 2 as provided on input
Demand record.
Address Line
2
17. Submitted 15 317-331 Text Insurer/TPA Demand Mailing
Insurer/TPA City as provided on input record.
Demand
Mailing City
18. Submitted 2 332-333 Alpha Insurer/TPA Demand Mailing
Insurer/TPA State as provided on input record.
Demand
Mailing State
19. Submitted 9 334-342 Alpha-Numeric Insurer/TPA Demand Mailing Zip
Insurer/TPA as provided on input record.
Demand
Mailing Zip
20. Applied 32 343-374 Text Insurer/TPA Demand Address
Insurer/TPA Line 1, after address validation
Demand completed, which will be used by
Address Line Medicare for subsequent
1 processing. Demand Address
Change Flag (Field 41) will equal
Y if the applied address in Fields
20 – 24 is different from the
submitted address (Fields 15 – 19)
and N if it is the same as the
submitted address. Will contain
spaces if the TIN record was
rejected.
21. Applied 32 375-406 Text Insurer/TPA Demand Address
Insurer/TPA Line 2 after address validation
Demand completed. See description for
Address Line Field 20.
2

A-35
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

22. Applied 13 407-419 Text Insurer/TPA Demand Mailing
Insurer/TPA City after address validation
Demand completed. See description for
Mailing City Field 20.
23. Applied 2 420-421 Alpha Insurer/TPA Demand Mailing
Insurer/TPA State after address validation
Demand completed. See description for
Mailing State Field 20.
24. Applied 9 422-430 Alpha-numeric Insurer/TPA Demand Mailing Zip
Insurer/TPA after address validation
Demand completed. See description for
Mailing Zip Field 20.
25. Submitted 32 431-462 Text Foreign Employer Address Line 1
Foreign as provided on input record.
Employer
Address Line
1
26. Submitted 32 463-494 Text Foreign Employer Address Line 2
Foreign as provided on input record.
Employer
Address Line
2
27. Submitted 32 495-526 Text Foreign Employer Address Line 3
Foreign as provided on input record.
Employer
Address Line
3
28. Submitted 32 527-558 Alpha Foreign Employer Address Line 4
Foreign as provided on input record.
Employer
Address Line
4
29. TIN Disp 2 559-560 Alpha Code to indicate validation
Code processing results of the
submitted TIN Reference File
Detail Record:
‘01’ – TIN Record accepted
‘TN’ – TIN Record rejected
30. TIN Error 4 561-564 Alpha-numeric Code indicating an error was
Code 1 found on the input record. Refer
to the TN Error Code Table.
31. TIN Error 4 565-568 Alpha-numeric Code indicating an error was
Code 2 found in the on the input record.
Refer to the TN Error Code Table.
32. TIN Error 4 569-572 Alpha-numeric Code indicating an error was
Code 3 found on the input record. Refer
to the TN Error Code Table.

A-36
GHP User Guide Appendix A: MSP File Specifications

Field Name Size Displacement Data Type Description

33. TIN Error 4 573-576 Alpha-numeric Code indicating an error was
Code 4 found on the input record. Refer
to the TN Error Code Table.
34. TIN Error 4 577-580 Alpha-numeric Code indicating an error was
Code 5 found on the input record. Refer
to the TN Error Code Table.
35. TIN Error 4 581-584 Alpha-numeric Code indicating an error was
Code 6 found on the input record. Refer
to the TN Error Code Table.
36. TIN Error 4 585-588 Alpha-numeric Code indicating an error was
Code 7 found on the input record. Refer
to the TN Error Code Table.
37. TIN Error 4 589-592 Alpha-numeric Code indicating an error was
Code 8 found on the input record. Refer
to the TN Error Code Table.
38. TIN Error 4 593-596 Alpha-numeric Code indicating an error was
Code 9 found on the input record. Refer
to the TN Error Code Table.
39. TIN Error 4 597-600 Alpha-numeric Code indicating an error was
Code 10 found on the input record. Refer
to the TN Error Code Table.
40 Mailing 1 601-601 Alpha-numeric Code indicating whether
Address Submitted Address (Fields 3-7)
Change Flag differs from the Applied Address
(Fields 8 -12).
Values:
Y – address changed
N – address did not change
Space – record could not be
validated
41. Demand 1 602-602 Alpha-numeric Code indicating whether
Address Submitted Insurer/TPA Demand
Change Flag Mailing (Fields 15 – 19) differs
from the Applied Insurer/TPA
Demand Mailing Address (Fields
20 – 24).
Values:
Y – address changed
N – address did not change
Space – record could not be
validated.
42. Filler 48 603-650 Alpha-numeric Filled with spaces.

A-37
GHP User Guide Appendix A: MSP File Specifications

TIN Reference Response File Trailer Record

Table A-12: Section 111 GHP MSP TIN Reference File Trailer Record - 800 bytes
Field Name Size Displacement Data Type Description
1. Trailer 2 1-2 Alphanumeric Contains a value of ‘T0’.
Indicator
2. Section 111 9 3-11 Numeric ID number assigned by the BCRC.
RRE ID
3. File Type 4 12-15 Alpha ‘TGRP’ – TIN Reference Response
file.
4. File Date 8 16-23 Numeric Date CCYYMMDD
5. Record 9 24-32 Numeric Number of TIN Reference Response
Count File Detail Records in this file. Does
not include the Header and Trailer
Records in the Record Count.
6. Filler 618 33-650 Alphanumeric Filled with spaces.

A-38
GHP User Guide Appendix B: Query Only HEW File Specifications

Appendix B Query Only HEW File Specifications

Section 111 Query Only Input File (ANSI X12 270/271 Entitlement Query HEW Flat File
Format)
Note: These file layouts are for use with the HIPAA Eligibility Wrapper (HEW) software
supplied by the BCRC to process the ASC X12 270/271.
Mainframe and Windows PC/Server-based versions of the HEW software are available. You
may download the latest Windows version of the HEW software after logging on to the Section
111 COBSW at https://www.cob.cms.hhs.gov/Section111/.You may request a copy of both the
mainframe and Windows versions from your EDI Representative or by contacting the EDI
Department at 646-458-6740.
Note: When using the HEW software, RREs should select the “COB” processing format for the
Section 111 output file.
If you choose to use your own ANSI X12 translator to create the ANSI X12 270 files for the
Section 111 Query Only File and process the X12 271 response, download the 270/271 Health
Care Eligibility Benefit Inquiry and Response Companion Guide for Mandatory Reporting GHP
Entities document located at the bottom of the cms.gov website. This document includes the X12
270/271 mapping required for Section 111.
HEW Query Only Input File Header Record—Version 4.0.0

Table B-1: Section 111 HEW V4.0.0 Query Only Input File Header Record - 200 bytes
Field Name Size Displacement Description
1. Header Indicator 2 1-2 Must be: ‘H0’.
Required.
2. Section 111 RRE ID (RRE 9 3-11 ‘000000001’, ‘000000002’, etc. ID
ID) number assigned by the BCRC.
Required.
3. File Type 4 12-15 Must be ‘IACT’.
Required.
4. File Date 8 16-23 Date RRE created or transmitted the file.
(CCYYMMDD).
Required.
5. Filler 177 24-200 Unused Field.
Fill with spaces.

B-1
GHP User Guide Appendix B: Query Only HEW File Specifications

HEW Query Only Input File Detail Record—Version 4.0.0

Table B-2: Section 111 HEW V4.0.0 Query Only Input File Detail Record - 200 bytes
Field Name Size Displacement Description
1. Medicare ID 12 1-12 Medicare ID (Health Insurance Claim
Number [HICN] or Medicare Beneficiary
Identifier [MBI])
Note: This is also known as the Medicare
Number to CMS’ Medicare beneficiaries.
Required if SSN not provided.
2. Last Name 6 13-18 First 6 characters of the last name of Covered
Individual.
Provide the last name as it appears on the
individual’s SSN or Medicare Card.
Required.
3. First Initial 1 19-19 First Initial of Covered Individual.
Provide the first initial as it appears on the
individual’s SSN or Medicare Card.
Required.
4. DOB 8 20-27 Covered Individual's Date of Birth
(CCYYMMDD).
Required.
5. Sex Code 1 28-28 Covered Individual's Gender:
0 = Unknown*
1 = Male
2 = Female
Required.
*If a value of ‘0’ is submitted, the BCRC will
change it to ‘1’ for matching purposes.
6. SSN 9 29-37 Social Security Number of the Covered
Individual.
Required if Medicare ID not provided.
7. RRE DCN 1 30 38-67 Primary identifier assigned to record by RRE
for tracking. Will be returned on the
corresponding response record.
8. RRE DCN 2 30 68-97 Secondary identifier assigned to record by
RRE for tracking. Will be returned on the
corresponding response record.
9. Filler 103 98-200 Unused field.
Fill with spaces.

B-2
GHP User Guide Appendix B: Query Only HEW File Specifications

HEW Query Only Input File Trailer Record – Version 4.0.0

Table B-3: Section 111 HEW V4.0.0 Query Only Input File Trailer Record - 200 bytes
Field Name Size Displacement Description
1. Trailer Indicator 2 1-2 Must be: ‘T0’
2. Section 111 Reporter ID 9 3-11 ‘000000001’, ‘000000002’, etc. ID number
(RRE ID) assigned by the . Must match RRE ID used
on the header record.
Required.
3. File Type 4 12-15 Must be ‘IACT’.
Required.
4. File Date 8 16-23 Date RRE created or transmitted the file.
Must match the date used on the header
record. (CCYYMMDD).
Required.
5. Record Count 9 24-32 Number of individual query records in this
file. Do not include the Header and Trailer
Records in the Record Count.
Required.
6. Filler 168 33-200 Unused Field.
Fill with spaces.

B-3
GHP User Guide Appendix B: Query Only HEW File Specifications

HEW Query Only Response File Record - Version 4.0.0

Note: The HEW Query Only Response File does not have a header or trailer record.

Table B-4: Section 111 HEW V4.0.0 Query Only Response File Record - 300 bytes
Field Name Size Displacement Description
1. Medicare ID 12 1-12 Current Medicare ID (Health
Insurance Claim Number [HICN]
or Medicare Beneficiary Identifier
[MBI]).
BCRC-supplied if individual was
matched to a Medicare beneficiary.
Store this identifier in your internal
system and use it on all subsequent
transactions.
Note: This is also known as the
Medicare Number to CMS’
Medicare beneficiaries.
2. Last Name 6 13-18 First 6 characters of the last name
of Covered Individual. BCRC
supplied if individual was matched
to a Medicare beneficiary.
3. First Initial 1 19-19 First Initial of Covered Individual.
BCRC supplied if individual was
matched to a Medicare beneficiary.
4. DOB 8 20-27 Covered Individual's Date of Birth
(CCYYMMDD).
BCRC supplied if individual was
matched to a Medicare beneficiary.
5. Sex Code 1 28-28 Covered Individual's Gender:
1 = Male*
2 = Female
BCRC supplied if individual was
matched to a Medicare beneficiary.
*If ‘0’ was submitted on the input
record then the BCRC will change
this value to ‘1’ regardless of a
match.
6. SSN 9 29-37 Social Security Number of the
Covered Individual as submitted on
the input record.
7. Entitlement Reason 1 38 Reason for Medicare Entitlement:
(Medicare reason) A = Aged
B = ESRD
G = Disabled
BCRC supplied.

B-4
GHP User Guide Appendix B: Query Only HEW File Specifications

Field Name Size Displacement Description

8. Current Medicare Part A 8 39-46 Effective Date of Medicare Part A
Effective Date Coverage (CCYYMMDD).
BCRC supplied.
9. Current Medicare Part A 8 47-54 Termination Date of Medicare Part
Termination Date* A Coverage (CCYYMMDD).
* Blank if ongoing.
BCRC supplied.
10. Current Medicare Part B 8 55-62 Effective Date of Medicare Part B
Effective Date Coverage (CCYYMMDD).
BCRC supplied.
11. Current Medicare Part B 8 63-70 Termination Date of Medicare Part
Termination Date* B Coverage (CCYYMMDD).
*Blank if ongoing.
BCRC supplied.
12. Medicare Beneficiary Date of 8 71-78 Beneficiary Date of Death
Death (CCYYMMDD).
BCRC supplied.
13. Current Medicare Part C Plan 5 79-83 Contractor Number of the current
Contractor Number Part C Plan in which the
beneficiary is enrolled.
BCRC supplied.
14. Current Medicare Part C Plan 8 84-91 Effective Date of coverage
Enrollment Date provided by the beneficiary’s
current Medicare Part C Plan
(CCYYMMDD).
BCRC supplied.
15. Current Medicare Part C Plan 8 92-99 Termination Date of the coverage
Termination Date* provided by the beneficiary’s
current Medicare Part C Plan
(CCYYMMDD).
*Blank if ongoing.
BCRC supplied.
16. Disposition Code 2 100-101 01 = Record Accepted. Individual
was matched to a Medicare
beneficiary.
51 = Individual was not matched to
a Medicare beneficiary.
BCRC supplied.
17. CMS Document Control 15 102-116 BCRC generated record tracking
Number number.
BCRC supplied.
18. RRE DCN 1 30 117-146 Primary identifier assigned to
record by RRE for tracking as
submitted on the input record.

B-5
GHP User Guide Appendix B: Query Only HEW File Specifications

Field Name Size Displacement Description

19. RRE DCN 2 30 147-176 Secondary identifier assigned to
record by RRE for tracking as
submitted on the input record.
20. Filler 124 177-300 Future Use

B-6
GHP User Guide Appendix C: Non-MSP File Specifications

Appendix C Non-MSP File Specifications

Section 111 GHP Non-MSP Input File – Expanded Reporting Option
Only
Non-MSP Input File Header Record

Table C-1: Section 111 GHP Non-MSP Input File Header Record - 300 bytes
Field Name Size Displacement Data Type Description
1. Header 2 1-2 Alpha-Numeric Must be: ‘H0’
Indicator
2. Section 111 9 3-11 Numeric ‘000000001’, ‘000000002’, etc. ID
RRE ID number assigned by the BCRC.
Required.
3. File Type 4 12-15 Alpha Must be: ‘NMSI’ – Non-MSP
Input File.
4. File Date 8 16-23 Numeric CCYYMMDD
Required.
5. RDS 10 24-33 Alpha-Numeric Retiree Drug Subsidy ID number
Application that is associated with a particular
Number RDS application. Assigned by the
RDS Center. When populated, this
field should contain 10 digits (0-9),
right justified with leading
positions zero filled. This
application number will change
each year when a new application
is submitted.
Required for files containing
Action Type S (S Records). Fill
with spaces for files containing
Action Types D and N (D/N
Records).
6. Filler 267 34-300 Filler Unused Field.

C-1
GHP User Guide Appendix C: Non-MSP File Specifications

Non-MSP Input File Detail Record

Table C-2: Section 111 GHP Non-MSP Input File Detail Record - 300 bytes
Field Name Size Displacement Data Type Description
1. Beneficiary 9 1-9 Numeric Inactive Covered Individual’s
Social Social Security Number.
Security Required if Medicare ID field
Number (below) not populated.
Fill with spaces if SSN is not
available.
2. Medicare ID 12 10-21 Alpha- Inactive Covered Individual’s
Numeric Medicare ID (Health Insurance
Claim Number [HICN] or
Medicare Beneficiary Identifier
[MBI])
Note: This is also known as the
Medicare Number to CMS’
Medicare beneficiaries.
Required if SSN field (above)
not populated.
Populate with spaces if not
available.
3. Covered 6 22-27 Text Inactive Covered Individual’s Last
Individual’s Name – Required.
Surname Report the last name as it appears
on the individual’s SSN or
Medicare Card.
4. Covered 1 28-28 Alpha Inactive Covered Individual’s
Individual’s First Initial – Required.
First Initial Report first initial as it appears on
the individual’s SSN or Medicare
Card.
5. Covered 1 29-29 Alpha Inactive Covered Individual’s
Individual’s Middle Initial – Optional.
Middle Initial
6. Covered 8 30-37 Numeric Date Inactive Covered Individual’s
Individual’s DOB (CCYYMMDD).
Date of Birth Required.
7. Covered 1 38-38 Numeric Inactive Covered Individual’s Sex
Individual’s Valid values:
Sex Code
0 = Unknown
1 = Male
2 = Female
Required.

C-2
GHP User Guide Appendix C: Non-MSP File Specifications

Field Name Size Displacement Data Type Description

8. Group Health 20 39-58 Text GHP Number assigned by Payer
Plan (GHP) for Action Type D, or, Unique
Number Benefit Option Identifier, as
defined by the RDS Center,
assigned by Payer for Action Type
S. For more information on
formatting S records, refer to the
RDS User Guide on
https://rds.cms.hhs.gov under the
User Guides menu option.
For use with Action Types D and
S.
Required for Action Type S
when Coverage Type is V, Z, 4,
5 or 6.
9. Individual 17 59-75 Text Unique Identifier assigned by the
Policy payer to identify the covered
Number individual. For use with Action
Types D and S. Required for
Action Type D when Coverage
Type is V, Z, 4, 5, and 6.
10. Effective 8 76-83 Numeric Date Start Date of Covered Individual’s
Date GHP Coverage by Insurer
(CCYYMMDD).
Required for Action Types D
and S.
11. Termination 8 84-91 Numeric Date End Date of Covered Individual’s
Date** GHP Coverage by Insurer
(CCYYMMDD).
For use with Action Types D and
S.
Required for Action Type S.
**All zeros if open-ended.
12. National 10 92-101 Filler National Health Plan Identifier.
Health Plan (Future Use.)
13. Rx Insured 20 102-121 Text Insured’s Rx Identification
ID Number Number.
For use with Action Types D and
S.
Required for Action Type D
when Coverage Type = U, W, X,
or Y.
Required for Action Type S,
cannot be blank or all zeros
(effective 04/05/2021).

C-3
GHP User Guide Appendix C: Non-MSP File Specifications

Field Name Size Displacement Data Type Description

14. Rx Group 15 122-136 Text Rx Group Health Plan Number
Number assigned by Payer for Action Type
D, or, Unique Benefit Option
Identifier, as defined by the RDS
Center, and assigned by Payer for
Action Type S. For more
information on formatting S
records, refer to the RDS User
Guide on https://rds.cms.hhs.gov
under the User Guides menu
option.
No longer required (effective
04/05/21)
15. Rx PCN 10 137-146 Text Rx Processor Control Number for
Medicare Beneficiaries.
For use with Action Type D and S
when Coverage Type = U, W, X,
or Y.
Required if available.
Cannot have special characters,
except for a non-leading dash,
and no leading space (effective
04/05/2021)
16. Rx BIN 6 147-152 Numeric Benefit Identification Number for
Number Rx processing - Medicare
Beneficiaries.
For use with Action Types D and
S.
Required for Action Type D
when Coverage Type = U, W, X,
or Y.
Must be a 6-digit number.
Required for Action Type S,
cannot be all the same number
(effective 04/05/2021)
17. Rx Toll Free 18 153-170 Text plus “(“ Toll Free Number Pharmacist can
Number and “)” use to contact Rx Insurer.
For use with Action Types D and
S.

C-4
GHP User Guide Appendix C: Non-MSP File Specifications

Field Name Size Displacement Data Type Description

18. Relationship 2 171-172 Numeric Covered Individual’s Relation to
Code Policy Holder:
Valid values:
‘01’ = Covered Individual is
Policy Holder
‘02’ = Spouse or Common Law
Spouse
‘03’ = Child
‘20’ = Domestic Partner
‘04’ = Other
Or spaces.
Required for Action Types D
and S.
19. DCN 15 173-187 Text Document Control Number;
assigned by the Section 111 GHP
RRE.
Required. Each record within the
current file must have a unique
DCN.
20. Action Type 1 188 Alpha Type of Record:
Valid values:
‘D’ = Drug Reporting record
‘S’ = Subsidy Reporting record
‘N’ = Non-Reporting record
Required.
21. Transaction 1 189 Alpha- Type of Transaction:
Type Numeric Valid values:
‘0’ = Add record
‘1’ = Delete record
‘2’ = Update record
Fill with space for Action Type N.
Required for Action Types D or
S.

C-5
GHP User Guide Appendix C: Non-MSP File Specifications

Field Name Size Displacement Data Type Description

22. Coverage 1 190 Alpha- Type of Coverage:
Type Numeric • ‘U’ - Drug Only - network
Rx
• ‘V’ - Drug Only - non-
network Rx
• ‘W’ - Comprehensive
Coverage -
Hosp/Med/Drug - network
Rx
• ‘X’ - Hospital and Drug -
network Rx
• ‘Y’ - Medical and Drug -
network Rx
• ‘Z’ - Health
Reimbursement
Arrangement - non-
network Rx
• ‘4’ = Comprehensive
Coverage -
Hosp/Med/Drug - non-
network Rx
• ‘5’ = Hospital and Drug -
non-network Rx
• ‘6’ = Medical and Drug -
non-network Rx
Required for Action Types D or
S.
23. Person Code 3 191-193 Text Person Code the plan uses to
identify specific individuals on a
policy.
For use with Action Types D and
S.
24. Reserved 10 194-203 Internal use Reserved for COB internal use.
Fill with spaces only.
25. Reserved 5 204-208 Internal use Reserved for BCRC internal use.
Fill with spaces only.
26. Reserved 1 209 Internal use Reserved for BCRC internal use.
Fill with spaces only.
27. Insurer Name 32 210-241 Text Name of Insurance company
providing Prescription Drug
coverage. For use with Action
Types D and S.
Required for Action Type D
effective 10/1/2018.
Required for Action Type S
effective 4/1/2020.
28. Filler 59 242-300 Filler Unused field.

C-6
GHP User Guide Appendix C: Non-MSP File Specifications

Non-MSP Input File Trailer Record

Table C-3: Section 111 GHP Non-MSP Input File Trailer Record - 300 bytes
Field Name Size Displacement Data Type Description
1. Trailer 2 1-2 Alpha-Numeric Must be: ‘T0’
Indicator
2. Section 111 9 3-11 Numeric ‘000000001’, ‘000000002’, etc. ID
RRE ID number assigned by the BCRC.
Required.
3. File Type 4 12-15 Alpha Must be: ‘NMSI’ – Non-MSP
Input File.
4. File Date 8 16-23 Numeric CCYYMMDD
Required.
5. S Record 9 24-32 Numeric Number of Action Type ‘S’ records
Count on file.
Required.
6. D Record 9 33-41 Numeric Number of Action Type ‘D’ records
Count on file.
Required.
7. N Record 9 42-50 Numeric Number of Action Type ‘N’ records
Count on file.
Required.
8. Total Record 9 51-59 Numeric Number of detail records in this file.
Count Do not include the Header and
Trailer Records in the Record
Count.
Required.
9. Filler 241 60-300 Filler Unused Field.

C-7
GHP User Guide Appendix C: Non-MSP File Specifications

Section 111 GHP Non-MSP Response File

Non-MSP Response File Header Record

Table C-4: Section 111 GHP Non-MSP Response File Header Record - 500 bytes
Field Name Size Displacement Description
1. Header 2 1-2 Must be: ‘H0’
Indicator
2. Section 111 9 3-11 ‘000000001’, ‘000000002’, etc. ID number assigned
RRE ID by the BCRC.
Corresponds to the RRE ID submitted on the Non-
MSP Input File.
3. File Type 4 12-15 ‘NMSR’ – Non-MSP Response file.
‘RDSU’ – Unsolicited RDS Response File.
4. File Date 8 16-23 CCYYMMDD
COB supplied.
5. RDS 10 24-33 Retiree Drug Subsidy ID number assigned by the
Application RDS contractor that is associated with a particular
Number RDS application. This application number will
change each year when a new application is
submitted.
Field will contain value supplied on input.
6. Filler 467 34-500 Unused Field. Space filled.

C-8
GHP User Guide Appendix C: Non-MSP File Specifications

Non-MSP Response File Detail Record

Table C-5: Section 111 GHP Non-MSP Response File Detail Record - 500 bytes
Field Name Size Displacement Description
1. Filler 4 1-4 BCRC use.
2. SSN 9 5-13 Beneficiary’s SSN.
Included for Action Types D, S, and N.
Field will contain the value supplied on input record.
3. Medicare ID 12 14-25 Beneficiary’s Medicare ID (Health Insurance Claim
Number [HICN] or Medicare Beneficiary Identifier
[MBI]).
Included for Action Types D, S, and N.
If the information submitted on the input record was
matched to a Medicare beneficiary, this field will
contain the most current Medicare ID for the
beneficiary.
Store this Medicare ID in your system for future
updates and deletes.
Note: This is also known as the Medicare Number to
CMS’ Medicare beneficiaries.
4. Covered 6 26-31 Beneficiary’s Last Name.
Individual’s Included for Action Types D, S, and N.
Surname
Field will contain either the name supplied or a
corrected name from BCRC database.
5. Beneficiary First 1 32 Beneficiary’s First Initial.
Initial Included for Action Types D, S, and N.
Field will contain either the value supplied or a
corrected value from BCRC database.
6. Beneficiary 1 33 Beneficiary’s Middle Initial.
Middle Initial Included for Action Types D, S, and N.
Field will contain the value supplied.
7. Beneficiary Date 8 34-41 Beneficiary’s DOB (CCYYMMDD).
of Birth Included for Action Types D, S, and N.
Field will contain either the value supplied or a
corrected value from BCRC database.
8. Beneficiary Sex 1 42 Beneficiary’s Sex:
Code 0 = Unknown
1 = Male
2 = Female
Included for Action Types D, S, and N.
Field will contain either the value supplied or a
corrected value from COB database.

C-9
GHP User Guide Appendix C: Non-MSP File Specifications

Field Name Size Displacement Description

9. Group Health 20 43-62 GHP Number assigned by Payer for Action Type D,
Plan Number or, Unique Benefit Option Identifier, as defined by
the RDS Center, and assigned by Payer for Action
Type S.
Included for Action Types D and S.
Field will contain the value supplied on input.
10. Individual Policy 17 63-79 Policy Number.
Number Included for Action Types D and S.
Field will contain the value supplied on input.
11. Effective Date 8 80-87 Start Date of Beneficiary’s Supplemental Drug
Insurance Coverage (CCYYMMDD).
Included for Action Types D and S.
Field will contain the effective date applied to the
supplemental drug coverage record.
12. Termination Date 8 88-95 End Date of Beneficiary’s Supplemental Drug
Insurance Coverage (CCYYMMDD).
**All zeros if open-ended or non-applicable.
Included for Action Types D and S.
Field will contain the term date applied to the
supplemental drug coverage record.
13. National Health 10 96-105 National Health Plan Identifier. For Action Types D
Plan ID and S. (Future Use).
14. Rx Insured ID 20 106-125 Insured’s Rx Identification Number.
Number Included for Action Types D and S.
Field will contain the value supplied on input.
15. Rx Group 15 126-140 Rx Group Health Plan Number assigned by payer for
Number Action Type D or Unique Benefit Option Identifier
assigned by payer for Action Type S.
Included for Action Types D and S.
Field will contain the value supplied on input.
16. Rx PCN 10 141-150 Rx Processor Control Number.
Included for Action Types D and S.
Field will contain the value supplied on input.
17. Rx BIN Number 6 151-156 Benefit Identification Number for Rx processing.
Included for Action Types D and S.
Field will contain the value supplied on input.
18. Rx Toll Free 18 157-174 Pharmacy benefit Toll Free Number.
Number Included for Action Types D and S.
Field will contain the value supplied on input.
19. Person Code 3 175-177 Person Code the Plan uses to identify specific
individuals on a policy.
Included for Action Types D and S.
Defaults to ‘001’ for D records if not provided on
input.

C-10
GHP User Guide Appendix C: Non-MSP File Specifications

Field Name Size Displacement Description

20. Relationship 2 178-179 Beneficiary’s Relationship to active employee:
Code ‘01’ = Beneficiary is Policy Holder
‘02’ = Spouse or Common Law Spouse
‘03’ = Child
‘20’ – Domestic Partner
‘04’ = Other
Included for Action Types D and S.
Field will contain the value supplied on input.
21. RRE Assigned 15 180-194 The Document Control Number assigned by the
DCN Section 111 GHP RRE. Included for Action Types D,
S, and N.
Field will contain the value supplied on input.
22. BCRC DCN 15 195-209 BCRC Document Control Number.
Included for Action Types D, S, and N.
Field will contain the DCN created for this record by
the BCRC.
23. Original Action 1 210 Type of Record:
Type ‘D’ = Drug Reporting record
‘S’ = Subsidy Reporting record
‘N’ = Non-Reporting record
Included for Action Types D, S, and N.
Field will contain value supplied on input.
24. Action Type 1 211 Type of Record applied by BCRC (BCRC may change
an S action to a D if RDS rejects the record due to Part
D enrollment):
‘D’ = Drug Reporting record
‘S’ = Subsidy Reporting record
‘N’ = Non-Reporting record
Included for Action Types D, S and N.
BCRC supplied value.
25. Transaction Type 1 212 Type of Transaction:
‘0’ = Add record
‘1’ = Delete record
‘2’ = Update record
Included for Action Types D and S.
Field will contain value supplied on input.

C-11
GHP User Guide Appendix C: Non-MSP File Specifications

Field Name Size Displacement Description

26. Coverage Type 1 213 Type of Coverage:
‘U’ = Drug Only - network Rx
‘V’ = Drug Only - non-network Rx
‘W’ = Comprehensive Coverage - Hosp/Med/Drug -
network Rx
‘X’ = Hospital and Drug - network Rx
‘Y’ = Medical and Drug - network Rx
‘Z’ = Health Reimbursement Arrangement - non-
network Rx
‘4’ = Comprehensive Coverage - Hosp/Med/Drug -
non-network Rx
‘5’ = Hospital and Drug - non-network Rx
‘6’ = Medical and Drug - non-network Rx
Included for Action Types D and S.
Field will contain the value supplied on input.
27. Filler 1 214 Unused Field.
28. Reason for 1 215 Reason for Medicare Entitlement:
Medicare ‘A’ = Aged
Entitlement
‘B’ = ESRD
‘G’ = Disabled
Included for Action Types D and N.
BCRC-supplied value.

C-12
GHP User Guide Appendix C: Non-MSP File Specifications

Field Name Size Displacement Description

29. Disposition Code 2 216-217 Cross-walked result from RDS processing to BCRC
disposition codes.
Included for records submitted with ‘S’ Action Type.
RDS-supplied value converted to Section 111 GHP
specific S Disposition Code.
Values:
01 = Subsidy record accepted.
02 = Application pending or in process at RDS
(BCRC internal use).
03 = Rejected - Beneficiary record not found.
04 = Rejected - Beneficiary already enrolled in Part D.
05 = Rejected – Beneficiary not Medicare entitled.
06 = Rejected - Subsidy record rejected for errors.
07 = Rejected - Associated RDS application was
rejected.
08 = Rejected - Beneficiary deceased.
09 = Rejected – Missing header/trailer record (for
RDS interface only).
10 = Beneficiary has attempted to enroll in Part D.
Communicate with the beneficiary about his or her
intentions regarding the subsidy coverage.
11 = Resubmit previously rejected record (re:
unsolicited response input).
Refer to Field 53 (RDS Reason Code) and Field 54
(RDS Determination Indicator) for actual codes
supplied by the RDS Center.
30. S Disposition 8 218-225 Date S Disposition determined
Date (CCYYMMDD).
Included for records with an original S Action Type.
RDS Center supplied value.
31. Current Medicare 8 226-233 Effective Date of Medicare Part A Coverage
Part A Effective (CCYYMMDD).
Date Included for all Action Types.
BCRC supplied value.
32. Current Medicare 8 234-241 Termination Date of Medicare Part A Coverage
Part A (CCYYMMDD).
Termination Included for all Action Types.
Date*
BCRC supplied value.
* All zeros if open-ended or not applicable.
33. Current Medicare 8 242-249 Effective Date of Medicare Part B Coverage
Part B Effective (CCYYMMDD).
Date Included for all Action Types.
BCRC supplied value.

C-13
GHP User Guide Appendix C: Non-MSP File Specifications

Field Name Size Displacement Description

34. Current Medicare 8 250-257 Termination Date of Medicare Part B Coverage
Part B (CCYYMMDD).
Termination Included for all Action Types.
Date*
BCRC supplied value.
* All zeros if open-ended or not applicable.
35. Part D Eligibility 8 258-265 Earliest date that beneficiary is eligible to enroll in
Start Date Part D – Refer to Field 42 for the Part D Plan
Enrollment Date (CCYYMMDD).
Included for all Action Types.
BCRC supplied value.
36. Part D Eligibility 8 266-273 Date the beneficiary is no longer eligible to receive
Stop Date* Part D Benefits – Refer to Field 43 for the Part D Plan
Termination Date (CCYYMMDD).
Included for all Action Types.
BCRC supplied value.
* All zeros if open-ended or not applicable.
37. Medicare 8 274-281 Medicare Beneficiary Date of Death (CCYYMMDD).
Beneficiary Date Included for all Action Types.
of Death*
BCRC supplied value.
* All zeros if not applicable.
38. Current Medicare 5 282-286 Contractor Number of the current Part C Plan in which
Part C Plan the beneficiary is enrolled.
Contractor Included for all Action Types.
Number
BCRC supplied value.
39. Current Medicare 8 287-294 Effective Date of coverage provided by the
Part C Plan Beneficiary’s current Medicare Part C Plan
Enrollment Date (CCYYMMDD).
Included for all Action Types.
BCRC supplied value.
40. Current Medicare 8 295-302 Termination Date of the coverage provided by the
Part C Plan Beneficiary’s current Medicare Part C Plan
Termination (CCYYMMDD).
Date* Included for all Action Types.
BCRC supplied value.
* All zeros if open-ended or not applicable.
41. Current Medicare 5 303-307 Contractor Number of the Medicare Part D Plan.
Part D Plan Included for all Action Types.
Contractor
BCRC supplied value.
Number
42. Current Medicare 8 308-315 Effective Date of coverage provided by the Medicare
Part D Plan Part D Plan (CCYYMMDD).
Enrollment Date Included for all Action Types.
BCRC supplied value.

C-14
GHP User Guide Appendix C: Non-MSP File Specifications

Field Name Size Displacement Description

43. Current Medicare 8 316-323 Termination Date of coverage provided by the
Part D Plan Medicare Part D Plan (CCYYMMDD).
Termination Included for all Action Types.
Date*
BCRC supplied value.
* All zeros if open-ended or not applicable.
44. Error Code 1 4 324-327 Error Code 1 – May contain SP or Rx error codes
from BCRC or RDS processing if applicable.
See SP and Rx Error Code Tables for values.
BCRC supplied value for D/N records.
RDS supplied value for S records.
45. Error Code 2 4 328-331 Error Code 2 – May contain SP or Rx error codes
from BCRC or RDS processing if applicable.
See SP and Rx Error Code Tables for values.
BCRC supplied value for D/N records.
RDS supplied value for S records.
46. Error Code 3 4 332-335 Error Code 3 – May contain SP or Rx error codes
from BCRC or RDS processing if applicable.
See SP and Rx Error Code Tables for values.
BCRC supplied value for D/N records.
RDS supplied value for S records.
47. Error Code 4 4 336-339 Error Code 4 – May contain SP or Rx error codes
from BCRC or RDS processing if applicable.
See SP and Rx Error Code Tables for values.
BCRC supplied value for D/N records.
RDS supplied value for S records.
48. D/N Disposition 2 340-341 Result from processing of an Action Type D or N
Code record. This will also be used to provide a disposition
for D records converted from S records – in such case,
the S Disposition Code and Date (Fields 29 and 30)
will also be populated.
See GHP Disposition Code Table for values.
Code supplied by the BCRC.
49. D/N Disposition 8 342-349 Processing date associated with the D/N Disposition
Date Code (CCYYMMDD).
Supplied by the BCRC.
50. RDS Start Date 8 350-357 Start date for the RDS subsidy period
(CCYYMMDD).
RDS-supplied value.
51. RDS End Date 8 358-365 End date for RDS subsidy period (CCYYMMDD).
RDS-supplied value.
52. RDS Split 1 366 Indicates multiple subsidy periods within the plan
Indicator year. Expect multiple records. Values:
‘Y’ if applicable.
Space if not applicable.
RDS-supplied value.

C-15
GHP User Guide Appendix C: Non-MSP File Specifications

Field Name Size Displacement Description

53. RDS Reason 2 367-368 Spaces = Accepted
Code* 01=Application deadline missed
02=Invalid Application Number
03=Invalid Last Name
04=Invalid First Name
05=Invalid Date of Birth
06=Invalid Gender
07=Invalid Coverage Effective Date
08= Invalid Coverage Termination Date
09= Invalid Benefit Option Identifier (Rx Group
Number)
10= Enrolled in Part D
11= Not eligible for Medicare
12= Beneficiary is deceased
13= Invalid Medicare ID (HICN or MBI) or SSN
14=Termination Date less than Effective Date
15= Missing Trailer Record
16= Not a valid Medicare beneficiary
17= No coverage period exists for delete transaction
18= Invalid Action Type
19= Invalid Relationship Code
20= Beneficiary attempted to enroll in Part D and
received an initial rejection.
21= New Medicare information has been received –
resend record.
*RDS Center-supplied codes. The RDS User Guide
can be found on https://rds.cms.hhs.gov under the
User Guides menu option. The RDS User Guide
contains the most current and complete information
regarding RDS Determination and Reason Codes.
54. RDS 1 369 Y = Yes, the retiree qualifies for the RDS subsidy.
Determination N = No, the retiree does not qualify for the RDS
Indicator subsidy.
This indicator may be blank on records in
unsolicited RDS response files.
RDS supplied value.
55. ESRD Coverage 8 370-377 The date on which the beneficiary is entitled to
Period Effective Medicare in some part because of a diagnosis of End
Date Stage Renal Disease (CCYYMMDD). Last coverage
period will be reported if multiple coverage periods
exist.
Supplied by the BCRC.
56. ESRD Coverage 8 378-385 The date on which the beneficiary is no longer entitled
Period Term Date to Medicare under ESRD Provisions (CCYYMMDD).
Last coverage period will be reported if multiple
coverage periods exist.
Supplied by the BCRC.

C-16
GHP User Guide Appendix C: Non-MSP File Specifications

Field Name Size Displacement Description

57. First Dialysis 8 386-393 A date that indicates when the beneficiary first started
Date ESRD Dialysis (CCYYMMDD).
Supplied by the BCRC.
58. ESRD Self- 8 394-401 A date that indicates when the beneficiary participated
Training Date in ESRD Self Care Training (CCYYMMDD).
Supplied by the BCRC.
59. Transplant Date – 8 402-409 A date that indicates when a Kidney Transplant
Most Recent Operation Occurred (CCYYMMDD). Last occurrence
will be reported.
Supplied by the BCRC.
60. Transplant 8 410-417 A date that indicates when a Kidney Transplant failed
Failure Date – (CCYYMMDD). Last occurrence will be reported.
Most Recent Supplied by the BCRC.
61. Filler 83 418-500 Unused Field. Filled with spaces.

C-17
GHP User Guide Appendix C: Non-MSP File Specifications

Non-MSP Response File Trailer Record

Table C-6: Section 111 GHP Non-MSP Response File Trailer Record - 500 bytes
Field Name Size Displacement Description
1. Trailer Indicator 2 1-2 Must be: ‘T0’
2. Section 111 RRE ID 9 3-11 ‘000000001’, ‘000000002’, etc. ID number
assigned by the BCRC.
Corresponds to the RRE ID submitted on
the Non-MSP Input File and the Response
File Header Record.
3. File Type 4 12-15 ‘NMSR’ – Non-MSP Response File.
‘RDSU’ – Unsolicited RDS Response File.
Field will contain value supplied on input.
4. File Date 8 16-23 CCYYMMDD
COB supplied.
5. Record Count 9 24-32 Number of detail records in this file.
Header and trailer records are not
included in this count.
BCRC Supplied.
6. Filler 468 33-500 Unused Field. Space filled.

C-18
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

Appendix D Disposition, Error, and Compliance Codes

Section 111 GHP Disposition Codes

Table D-1: Section 111 GHP Disposition Codes

Disposition Codes Description
01 MSP and Non-MSP Response Files: Record accepted by the Medicare
Common Working File (CWF) or the Medicare Beneficiary Database (MBD)
as an “Add,” “Update,” or “Delete” record. An MSP occurrence or
supplemental drug record was added, updated or deleted.
Query Only Response File: The individual was found to be a Medicare
beneficiary and the response record contains Medicare entitlement and
enrollment information.
TIN Reference Response File: TIN Record accepted.
SP Transaction error: Record was found to be in error and rejected. Record
returned with at least one SP or Rx error (specific SP and Rx errors are
described below). Record must be corrected and resubmitted on the next file
submission unless otherwise specified in the error description.
50 Record still being processed by CMS. Internal CMS use only; resubmit
record on next file submission.
51 Individual was not found to be (could not be matched with) a Medicare
beneficiary; that is, the individual does not have Medicare Part A entitlement.
Record will not be recycled. (Note: Individuals may be Medicare
beneficiaries but have Medicare Part B coverage only. The MSP provision
does not apply to Medicare beneficiaries who only have Medicare Part B
coverage.) RRE should verify individual’ status based on information in its
files and resubmit record on next file submission as necessary.
RREs will also receive this disposition code if neither the Medicare ID
(Health Insurance Claim Number [HICN] or Medicare Beneficiary Identifier
[MBI]) nor SSN is submitted on the input record. In this case the RRE must
obtain a valid Medicare ID or SSN and resubmit the record on the next file
submission.
RREs will also receive this disposition code if the coverage dates fall
completely outside the Medicare entitlement period, if the record was
submitted prior to the effective date of the individual’s Medicare entitlement,
or if the coverage was terminated prior to the effective date of the individual’s
Medicare entitlement. (Effective April 5, 2021)
Note: The Medicare ID is also known as the Medicare Number to CMS’
Medicare beneficiaries.
52 Record still being processed by CMS. Internal CMS use only; resubmit
record on next file submission.
53 Record in alpha match at CMS. Internal CMS use only; resubmit record on
next file submission.
61 Cross-Reference Data Base Problem. Internal CMS use only; resubmit
record on next file submission
AB CWF problem that can only be resolved by CWF Technician. Internal CMS
use only; resubmit record on next file submission.
CI Processing Error. Internal CMS use only; resubmit record on next file
submission.

D-1
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

Disposition Codes Description

ID Drug Record Processing Error. Internal CMS use only; resubmit record on
next file submission.
BY Bypass. Record was bypassed. SEE Medicare ID (HICN or MBI) was
submitted by RRE and accepted; Do not resubmit the record unless the SEE
expires, GHP coverage continues, and the beneficiary meets the definition of
an Active Covered Individual. Refer to Section 7.2.4 for more information on
the Small Employer Exception.
RREs will also receive this disposition code if the employee’s status is shown
to be inactive (‘2’ in Field 20 of MSP Input File Detail Record) and the
individual was found to be entitled to Medicare due to age or disability (not
ESRD). This beneficiary is not an Active Covered Individual since he or she
is not entitled due to ESRD and not covered due to current employment of the
subscriber. Medicare is not secondary to the GHP coverage. Do not resubmit
the record.
TN TIN Reference File Detail Record rejected due to errors. Only returned on
TIN Reference Response File.
Record returned with at least one TN edit (specific TN error codes are
described below). Record must be corrected and resubmitted on the next file
submission.

D-2
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

Section 111 GHP SP Error Codes

Table D-2: Section 111 GHP SP Error Codes

Note: SP errors may be returned on the MSP Response File and the Non-MSP Response File.
However, not all SP errors apply to Non-MSP records. If you have any questions on how to
resolve a specific error, please contact your EDI Representative.
SP Error Description BCRC RRE
Code Responsible Responsible
SP11 Invalid MSP Transaction Record Type. No Yes No
correction necessary - resubmit records with
this error on your next file submission.
SP12 Invalid Medicare ID (Health Insurance Claim No Yes
Number [HICN] or Medicare Beneficiary Identifier
[MBI]) (Mandatory). Field must contain alpha and
numeric characters. Do not include
dashes/hyphens. You received this error because an
invalid character was found in this field.
Note: The Medicare ID is also known as the
Medicare Number to CMS’ Medicare beneficiaries.
SP13 Invalid Beneficiary/Individual Surname No Yes
(Mandatory). Field must contain alpha characters.
Field cannot begin with a space or contain all
spaces. Field cannot contain numeric characters.
SP14 Invalid Beneficiary/Individual First Name Initial No Yes
(Mandatory). Field must contain alpha characters.
First position cannot be blank or a space, a numeric
character, or a punctuation mark.
SP15 Invalid Beneficiary/Individual Date of Birth No Yes
(Mandatory). Field must contain numeric
characters. Field cannot be blank or contain spaces
or alpha characters. Day of the month must be
correct. For example, if month = 02 and day = 30,
the record will reject.
SP16 Invalid Beneficiary/Individual Sex Code No Yes
(Mandatory). Field must contain numeric
character. Field cannot be blank, contain spaces or
alpha characters. Acceptable numeric characters
include the following:
0 = Unknown
1 = Male
2 = Female
SP17 Invalid Contractor Number (Mandatory). No Yes No
correction necessary - resubmit records with
this error on your next file submission.
SP18 Invalid Document Control Number (DCN) Yes No
submitted by the BCRC to CWF. No correction
necessary - resubmit records with this error on
your next file submission.

D-3
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

SP Error Description BCRC RRE

Code Responsible Responsible
SP19 Invalid Transaction Type (Mandatory). This error No Yes
results from what is provided in the type of record
transaction field. Field must contain a numeric
character. Field cannot be blank, contain alpha
characters or spaces. Acceptable numeric
characters include the following:
0 = Add Record
1 = Delete Record
2 = Update Record
SP20 Invalid Validity Indicator. No correction Yes No
necessary - resubmit records with this error on
your next file submission.
SP21 Invalid MSP Code. No correction necessary - Yes No
resubmit records with this error on your next
file submission.

SP22 Invalid Diagnosis Code. No correction necessary Yes No

- resubmit records with this error on your next
file submission.
SP23 Invalid Remarks Code. No correction necessary - Yes No
resubmit records with this error on your next
file submission.
SP24 Invalid Coverage Type. No Yes
Valid Values:
‘J’ = Hospital Only
‘K’ = Medical Only
‘A’ = Hospital and Medical
‘U’ = Drug Only (network Rx)
‘V’ = Drug Only (non-network Rx)
‘W’ = Comprehensive Coverage –Hosp/Med/Drug
(network Rx)
‘X’ = Hospital and Drug (network Rx)
‘Y’ = Medical and Drug (network Rx)
‘Z’ = Prescription Drug Health Reimbursement
Account (non-network Rx)
‘4’ = Comprehensive Coverage –Hosp/Med/Drug
(non-network Rx)
‘5’ = Hospital and Drug (non-network Rx)
‘6’ = Medical and Drug (non-network Rx)
‘R’ = Health Reimbursement Arrangement (HRA)

D-4
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

SP Error Description BCRC RRE

Code Responsible Responsible
SP25 Invalid or no insurer name supplied. On the Non- No Yes
MSP Input Detail Record, when the submitted
Action Type (Field 20) is ‘D’ (Drug Reporting
record) or ‘S’ (Subsidy reporting record), RREs
must submit the Insurer Name (Field 27). Field 27
cannot be blank or contain only numeric characters
and spaces.
Field 27 cannot be equal to COBC,
COORDINATION OF BENEFITS
CONTRACTOR, COORDINATION OF
BENEFITS CONTRAC, SUPPLEMENT,
SUPPLEMENTAL, INSURER,
MISCELLANEOUS, CMS, ATTORNEY,
UNKNOWN, NONE, N/A, UN, UNK, MISC, NA,
NO, NO FAULT, NO-FAULT, BC, BX, BS, XX,
BCBS, BCBX, BLUE CROSS, BLUE SHIELD,
COB, HCFA, or MEDICARE.
Valid values: alphabetic, numeric, space, comma,
& - ' . @ # / : ;.
(Effective 10/1/2018 for ‘D’ records; effective
4/1/2020 for ‘S’ records.)
If an attempt is made to convert an ‘S’ (Subsidy)
record to a ‘D’ record and the insurer name is
missing or invalid, the SP25 error will be received.
SP30 Invalid or no insurer policy number supplied. On No Yes
the MSP Input Detail Record, RREs must submit
either the Policy Holder’s SSN (Field 15) – OR –
Individual Policy Number (Field 18). RREs are
encouraged to use Field 18 instead of Field 15 if
possible. Field 18 should reflect the unique
identifier the RRE uses for the individual being
reported on the record which in most cases is the
identification number shown on the individual’s
insurance card. The value supplied in these fields
will be placed on any related recovery demand
notifications for the RRE to use to identify the
GHP coverage for the individual reported on the
record.
Valid values: Alphabetic, Numeric, Space,
Comma, & - ' . @ # / ; :

D-5
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

SP Error Description BCRC RRE

Code Responsible Responsible
SP31 Invalid Effective Date (Mandatory). Field must No Yes
contain numeric characters. Field cannot be blank,
contain spaces, alpha characters or all zeros. The
date must be in the following format:
CCYYMMDD. Number of days must correspond
with the particular month. For example, the date
20110230 is not acceptable (February does not
have a day 30). Effective date must be less than or
equal to the current date and cannot be a future
date. For example, today is 20030312 and an RRE
submits a record with an effective date of
30000901. Since this is a future date, the RRE will
receive an SP31.
(Following deletion effective 04/05/2021)
[This error may also be returned if the individual is
found to be a Medicare beneficiary but the GHP
coverage dates fall completely outside the
Medicare entitlement period or the record was
submitted prior to the effective date of the
individual’s Medicare entitlement. Continue to
resend the record until the record is either
accepted, the individual is no longer an Active
Covered Individual, or your GHP coverage is
terminated. Alternatively, you may monitor the
Medicare status of the individual using the query
process and resend the associated MSP record
when Medicare entitlement is established or re-
established. To be deleted April 5, 2021]

D-6
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

SP Error Description BCRC RRE

Code Responsible Responsible
SP32 Invalid Termination Date (Mandatory). Field must No Yes
contain numeric characters. The date must be in the
following format: CCYYMMDD. Number of days
must correspond with the particular month. For
example, the date 20110230 is not acceptable
(February cannot have 30 days). Plan termination
date cannot be earlier than the effective date or
beneficiary’s eligibility start date.
If there is no termination date (coverage is still
active), you must use zeros (not spaces) in this
field. For Working-Aged beneficiaries, the
termination date cannot be greater than the current
date plus 6 months. For Disability beneficiaries,
the termination date cannot be greater than the first
day the beneficiary turned 65. Will accept future
date for ESRD up to 30 months.
(Following deletion effective 04/05/2021)
[This error could also be posted when the GHP
coverage and Medicare coverage do not overlap –
the GHP coverage ended prior to the start of
Medicare coverage. In this case, since the
individual is no longer considered to be an Active
Covered Individual due to GHP coverage
termination, the record does not need to be resent
unless the GHP coverage is reactivated at a later
date. See Section 7.2.8.2 for more information on
non-overlapping coverage. To be deleted April 5,
2021]
SP33 Invalid Relationship Code (Mandatory). Field must No Yes
contain numeric characters. Field cannot be blank
or contain alpha characters. Acceptable numeric
values are as follows:
01 = Self; Covered Individual is Policy Holder or
Subscriber
02 = Spouse or Common Law Spouse
03 = Child*
04 = Other
20 = Domestic Partner
*Applies only for children covered under the
ESRD provision or disabled adult children covered
under the disability provision.
SP34 Invalid Policy Holder/Subscriber First Name. Field No Yes
may contain alpha and/or numeric characters,
spaces, commas, & - ' . @ # / : ;. If field is not
used, field must contain spaces.
SP35 Invalid Policy Holder/Subscriber Last Name. Field No Yes
may contain alpha and/or numeric characters,
spaces, commas, & - ' . @ # / : ;. If field is not
used, field must contain spaces.

D-7
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

SP Error Description BCRC RRE

Code Responsible Responsible
SP36 Invalid Policy Holder SSN. If supplied, must be No Yes
numeric. If not used, default to spaces or all zeroes.
On MSP Input Detail Record, either Field 15
(Policy Holder’s SSN) or Field 18 (Individual
Policy Number) is required.
SP37 Invalid Source Code. No correction necessary - Yes No
resubmit records with this error on your next
file submission.
SP38 Invalid Employee Information Data Code. No Yes No
correction necessary - resubmit records with
this error on your next file submission.
SP44 Invalid Insurance Group Policy Number. Field may No Yes
contain alpha and/or numeric characters, commas,
& - ' . @ # / : ;.
SP45 Invalid Individual Policy Number. Field may No Yes
contain alpha and/or numeric characters, commas,
& - ' . @ # / : ;.
SP46 Invalid Pre-Paid Health Plan Date. No correction Yes No
necessary - resubmit records with this error on
your next file submission.
SP47 Delete transaction does not match to an existing No Yes
MSP occurrence. Beneficiary MSP Indicator not
on for delete transaction. An attempt was made to
delete an MSP record where there is no MSP
indicator on the beneficiary Medicare record.
According to CMS records Medicare has always
been the primary payer. No MSP occurrences exist
for this beneficiary.
SP48 Delete transaction does not match to an existing No Yes
MSP occurrence. Matching criteria on the delete
transaction may be incorrect, original add
transaction may not have been accepted with a ‘01’
disposition code, or the matching MSP occurrence
may have been deleted prior to the processing of
this transaction. Correct matching criteria and
resend as needed. If submitted matching criteria
was correct, no further action is necessary.

D-8
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

SP Error Description BCRC RRE

Code Responsible Responsible
SP49 Delete transaction does not match to an existing No Yes
MSP occurrence. MSP auxiliary occurrence not
found for delete data transaction. Where there is an
existing MSP period, the incoming record must
match on certain criteria so the system can
differentiate among various periods of MSP on the
beneficiary's Medicare file. These criteria are
patient relationship, MSP effective date, MSP type,
and coverage type. An SP 49 is received when an
RRE attempts to delete an occurrence that is not on
CWF, or one for which there is no "match" on
CWF, or you send in a delete transaction for a
record that has been previously deleted by the RRE
or another entity and the record no longer exists.
Matching criteria on the delete transaction may be
incorrect, original add transaction may not have
been accepted with a ‘01’ disposition code, or MSP
occurrence may have been deleted prior to the
processing of this transaction. Correct matching
criteria and resend as needed. If submitted
matching criteria was correct, no further action is
necessary.
SP50 Invalid function for update or delete. No Yes No
correction necessary - resubmit records with
this error on your next file submission.
SP51 MSP auxiliary record has 17 occurrences, and none Yes No
can be replaced. No correction necessary -
resubmit records with this error on your next
file submission.

D-9
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

SP Error Description BCRC RRE

Code Responsible Responsible
SP52 Invalid Relationship Code/MSP Code combination. No Yes
MSP determinations depend in part on the reason
for the beneficiary’s entitlement and the
relationship of the beneficiary to the subscriber.
The MSP Code (MSP Type based on reason for
entitlement) must correspond with valid
Relationship Codes as cited below.
MSP Code/ Relationship Codes
A = Working Aged
01 = Beneficiary
02 = Spouse
G = Disabled
01 = Beneficiary
02 = Spouse
03 = Child
04 = Other
20 = Domestic Partner
B = ESRD
01 = Beneficiary
02 = Spouse
03 = Child
04 = Other
20 = Domestic Partner
For example, this error may occur when the
covered individual submitted is a Medicare
beneficiary entitled due to age but their
relationship to the subscriber of the GHP
(employee) is not self (01) and not spouse (02).
Under these circumstances, the record was not
submitted in error. Instead it means that Medicare
is not secondary and the BCRC did not create an
MSP occurrence. In this case, the RRE cannot fix
this error but may continue to send the record until
the individual is no longer considered to be an
Active Covered Individual. Alternatively, the RRE
does not need to resend the record unless the
individual’s coverage information (i.e.,
relationship to the subscriber) changes.
SP53 MSP Code ‘G’ or ‘B’ overlaps another Code ‘A’, Yes No
‘G’, or ‘B’. No correction necessary - resubmit
records with this error on your next file
submission.

D-10
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

SP Error Description BCRC RRE

Code Responsible Responsible
SP54 MSP Code ‘A’ or ‘G’ has an effective date that is Yes No
in conflict with the calculated date the beneficiary
reaches 65 years old. For MSP Code ‘A’, the
effective date must not be less than the date at
age 65. For MSP Code ‘G’, the effective date must
not be greater than the date at age 65. No
correction necessary - resubmit records with
this error on your next file submission.
SP55 MSP Effective Date is less than the earliest Yes No
beneficiary Part A or Part B entitlement date. MSP
can only occur after the beneficiary becomes
entitled to Medicare Part A or Medicare Part B. An
MSP Effective Date that is an invalid date will also
cause SP 55 error. No correction necessary -
resubmit records with this error on your next
file submission.
SP56 MSP pre-paid health plan date must equal or be Yes No
greater than the MSP Effective Date or less than
MSP Termination Date. No correction necessary -
resubmit records with this error on your next
file submission.
SP57 Termination Date greater than 6 months before Yes No
date of accretion. No correction necessary -
resubmit records with this error on your next
file submission.
SP58 Invalid Coverage Type, MSP Code, and validity Yes No
indicator combination. Mapped coverage type must
equal ‘J’, ‘K’, or ‘A’. No correction necessary -
resubmit records with this error on your next
file submission.
SP59 Invalid insurer type and validity indicator Yes No
combination. RREs should not receive this edit. No
correction necessary - resubmit records with
this error on your next file submission.
SP60 Other coverage type for same period on file. RRE Yes No
submits a ’J‘ or ’K‘ coverage type, but Medicare's
CWF shows ’A‘ coverage type for the same period
of MSP. No correction necessary – verify
submitted information and resubmit records
with this error on your next file submission.
SP61 Other coverage type for same period on file. RRE Yes No
submits an ’A‘ coverage type, but Medicare's CWF
shows ’J‘ or ’K‘ coverage type for the same period
of MSP.
No correction necessary – verify submitted
information and resubmit records with this
error on your next file submission.

D-11
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

SP Error Description BCRC RRE

Code Responsible Responsible
SP62 Incoming termination date is less than MSP No Yes
Effective Date. MSP Termination Date provided
must be greater than the MSP Effective Date. The
RRE sent a Termination Date prior to the MSP
Effective Date. This edit occurs when an RRE fails
to note CMS' modification of the RRE's MSP
Effective Date to correspond with the
commencement of the Medicare entitlement date.
The RRE should go back to its previous response
file and identify the correct MSP Effective Date for
this record. If the Termination Date is earlier than
the MSP Effective Date on the previous response
file, this indicates that there was no MSP and the
RRE should send a transaction to delete the record.
SP66 MSP Effective Date is greater than the Effective Yes No
Date on matching occurrence on Auxiliary file. SP
66 occurs when the Effective Date on the
maintenance record is greater than the Effective
Date on the Auxiliary record to be updated, and
Effective Date plus 30 is greater than “+30.”
No correction necessary - resubmit records with
this error on your next file submission.
SP67 Not Used. Yes No
SP72 Invalid transaction attempted. No correction Yes No
necessary - resubmit records with this error on
your next file submission.
SP73 Invalid Termination Date/Delete Transaction Yes No
attempted. Internal CMS use only. No correction
necessary - resubmit records with this error on
your next file submission.
SP74 Invalid - cannot update 'I' record. No correction Yes No
necessary - resubmit records with this error on
your next file submission.
SP75 Invalid transaction. Beneficiary does not have No Yes
Medicare Part A benefits for the time period
identified in the RRE’s update file. If there is no
Part A entitlement, there is no MSP. No correction
necessary - resubmit records with this error on
your next file submission or monitor the
individual’s Medicare status using the query
file.
SP91 Invalid Employer Size (Mandatory). Field must No Yes
contain a numeric character. Field cannot be blank,
contain spaces or alpha characters. Acceptable
numeric characters include the following:
‘0’ = 1 to 19 employees
‘1’ = 20 to 99 employees
‘2’ = 100 or more employees

D-12
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

SP Error Description BCRC RRE

Code Responsible Responsible
SP99 Medicare ID (HICN or MBI) required if individual No Yes
is less than 45 years of age. In order to submit an
MSP Input File Detail Record for an individual
under age 45, the RRE must first obtain the
Medicare ID from the beneficiary or by using the
query process. No matching will be done by the
system on a record for an individual under age 45
unless the Medicare ID is submitted. RREs cannot
submit an MSP Input File Detail Record with only
the SSN for an individual under age 45. The
system will not attempt to match such a record to a
Medicare beneficiary and will not return the
Medicare ID if found. Instead the record will be
rejected with the SP99 error. See Section 7.2.8.2
for more.
SPES Due to the employer size, an MSP occurrence is No Yes
not created. Check that the employer size
submitted was correct and continue to resend the
record on all subsequent quarterly file submissions
until a ‘01’ disposition code is received, or the
individual is no longer covered by your plan. Since
the employer size may not change, you may
continue to receive a response record back with an
‘SP’ disposition code for these situations. See
Section 7.2.8.2for more information.
SPH0 Transaction attempted to update/delete an MSP No Yes
occurrence last updated by a higher-ranking
source. MSP occurrence is not locked, and the
RRE may submit an Override Code on the record
in its next quarterly file submission. RREs must
validate their information prior to resubmission to
make sure the override is appropriate.
SPH1 Transaction attempted to update/delete an MSP No Yes
occurrence locked by the BCRC. No update or
delete accepted via Section 111 reporting. Do
NOT attempt to resubmit this record. Insurer/TPA
RREs are advised to contact the associated
employer/other plan sponsor to verify the accuracy
of data submitted by the RRE. If changes are
necessary, contact the BCRC Monday through
Friday, from 8:00 a.m. to 8:00 p.m., Eastern Time,
except holidays, at toll-free lines: 1-855-798-2627
or TTY/TDD: 1-855-797-2627 for the hearing and
speech impaired.
SPH2 Transaction attempted to override the SPH0 error No Yes
without prior notification. RREs will receive this
error if they submit an Override Code on the first
attempt of the update/delete. You must first receive
the SPH0 error and then submit the Override Code
on the record in your next quarterly file submission
after verifying that the override is appropriate and
necessary.

D-13
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

SP Error Description BCRC RRE

Code Responsible Responsible
SPT0 No matching, valid TIN Reference File Detail No Yes
Record was found for the Employer TIN
submitted. Causes/resolutions:
An incorrect employer TIN was submitted on the
MSP Input File Detail Record. Correct and
resubmit MSP Input File Detail Record.
A corresponding TIN Reference File Detail Record
was not submitted for the employer TIN or was
submitted and rejected with errors. Refer to errors
returned on the TIN Reference Response File.
Submit updated/corrected TIN Reference File and
resubmit MSP Input File record.
SPT1 No matching, valid TIN Reference File Detail No Yes
Record was found for the Insurer/TPA TIN
submitted. Causes/resolutions:
An incorrect insurer/TPA TIN was submitted on
the MSP Input File Detail Record. Correct and
resubmit MSP Input File Detail Record.
A corresponding TIN Reference File Detail Record
was not submitted for the insurer/TPA TIN or was
submitted and rejected with errors. Refer to errors
returned on the TIN Reference Response File.
Submit updated/corrected TIN Reference File and
resubmit MSP Input File record.

D-14
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

Section 111 GHP Rx Error Codes

These codes only apply to records submitted for prescription drug coverage.

Table D-3: Section 111 GHP Rx Error Codes

Error Code Error Description
RX 01 Missing Rx ID
RX 02 Missing or invalid Rx BIN. Must be 6-digit number;
cannot be all the same number (effective April 5, 2021).
RX 03 Missing Rx Group Number
RX 04 Missing Group Policy Number
RX 05 Missing Individual Policy Number
RX 06 Missing/Invalid Retiree Drug Subsidy Application Number
RX 07 Beneficiary does not have Part D enrollment
RX 09 Invalid Action Code
RX 10 Record not found for delete
RX 11 Record not found for update
RX 12 Invalid Supplemental Type
RX 18 Invalid Rx PCN (effective April 5, 2021)

D-15
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

Section 111 SEE (Small Employer Exception) Response Codes

Table D-4: SEE Response Codes

Code Description
SA SEE-Medicare ID (HICN or MBI) accepted. Record bypassed and not submitted to
CWF. Disposition code of BY has been applied.
SN SEE-Medicare ID not-accepted. SEE Medicare ID could not be confirmed. Record
processed as normal MSP occurrence. Disposition code should be used to determine
subsequent processing required.
SP SEE-Medicare ID partially accepted. SEE Medicare ID confirmed, but insurance
effective period outside of SEE effective period. Disposition code should be used to
determine subsequent processing required.

D-16
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

Section 111 TIN Reference Response File Error Codes

Table D-5: GHP TIN Reference Response File Record Errors

Error Code Field Description
TN01 TIN - Field 1, TIN Indicator I Invalid Insurer/TPA TIN received on TIN
Reference record where the TIN Indicator
equals I. TIN cannot be validated by the BCRC.
Must be a 9-digit numeric code and must be a
valid, IRS-assigned TIN. TIN cannot be blank or
all spaces. If you believe the TIN to be valid,
contact your EDI Representative to supply
supporting evidence. Your EDI Representative
will then update the system to mark the TIN as
valid and then you may resend the record.
TN02 N/A Not used at this time.
TN03 Name – Field 2, TIN Indicator I Invalid Name (Insurer/TPA name) received on
the TIN Reference record where the TIN
Indicator equals I. Field cannot be blank. Must
contain at least 2 valid characters. The first two
characters cannot be blank. Spaces are allowed
between words in an insurer plan name. Field
may contain alpha and/or numeric characters,
commas, & - ' . @ # / : ;. Insurer name cannot
contain only the following word(s) as a default:
SUPPLEMENTAL, SUPPLEMENT,
INSURER, MISCELLANEOUS, CMS,
ATTORNEY, UNKNOWN, NONE, N/A, UN,
MISC, NA, NO, BC, BX, BS, BCBX, BLUE
CROSS, BLUE SHEILD, or MEDICARE.
Special characters other than, &, - ‘. @ # /: ; are
not allowed.
TN04 Address Line 1 – Field 3, TIN Invalid insurer/TPA Address Line 1 where the
Indicator I TIN Indicator equals I. Insurer/TPA Address
Line 1 field is missing or contains characters
other than alpha, numeric and special characters
A-Z, 0-9, space, &, dash, @, #, /, comma,
semicolon, colon, period, quote.
TN05 Address Line 2 – Field 4, TIN Invalid insurer/TPA Address Line 2 where the
Indicator I TIN Indicator equals I. If entered Address Line
2 must not contain any characters other than
alpha, numeric and special characters, A-Z, 0-9,
space, &, dash, @, #, /, comma, semicolon,
colon, period, quote.
TN06 City – Field 5, TIN Indicator I Invalid insurer/TPA City where the TIN
Indicator equals I. Insurer/TPA City is missing
or contains characters other than alpha and
special characters A-Z, space, &, dash, @, #, /,
comma, semicolon, colon, period, quote.
TN07 State – Field 6, TIN Indicator I Invalid insurer/TPA State where the TIN
Indicator equals I. Insurer/TPA State is missing
or contained a value other than a valid US postal
state code. A value of FC is NOT allowed for
the state code of the insurer/TPA.

D-17
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

Error Code Field Description

TN08 Zip Code – Field 7, TIN Indicator I Invalid or missing insurer/TPA Zip Code where
the TIN Indicator equals I. Zip Code must
contain 5 numeric digits or 9 numeric digits.
TN09 N/A Not used.
TN10 TIN Indicator – Field 8 Invalid TIN Indicator. Must contain one of the
following values:
E = The TIN field contains a valid TIN (EIN)
for an Employer.
I = The TIN field contains a valid TIN for an
Insurer/TPA.
S = The TIN field contains a valid TIN for the
plan sponsor of a multiple employer/multi-
employer plan.
F = The TIN field contains a valid TIN for a
Federal employer.
Z = The TIN field reflects a foreign employer
that has no valid TIN. The TIN field contains a
fake or pseudo-TIN for the foreign employer.
TN11 Insurer/TPA Demand Mailing Invalid Insurer/TPA Demand Mailing Name.
Name – Field 9, TIN Indicator I The field contains a value other than spaces but
the TIN Indicator was not equal to I. The TIN
Indicator is I, but the field contains characters
other than alpha, numeric and special characters
A-Z, 0-9, space, &, dash, @, #, /, comma,
semicolon, colon, period, quote. The TIN
Indicator is I, the Insurer/TPA Demand Address
Line 1 is non-blank but the Insurer/TPA
Demand Mailing Name is blank.
TN12 Insurer/TPA Demand Address Line Invalid Insurer/TPA Demand Address Line 1.
1 – Field 10, TIN Indicator I The field contains a value but the TIN Indicator
was not equal to I. The TIN Indicator is I and a
non-blank Insurer/TPA Demand Mailing Name
was supplied, but the Insurer/TPA Demand
Address Line 1 is missing or the field contains
characters other than alpha, numeric and special
characters A-Z, 0-9, space, &, dash, @, #, /,
comma, semicolon, colon, period, quote.
TN13 Insurer/TPA Demand Address Line Invalid Insurer/TPA Demand Address Line 2.
2 – Field 11, TIN Indicator I The field contains a non-blank value but the TIN
Indicator was not equal to I. The TIN Indicator
is I, but the field contains characters other than
alpha, numeric and special characters A-Z, 0-9,
space, &, dash, @, #, /, comma, semicolon,
colon, period, quote.

D-18
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

Error Code Field Description

TN14 Insurer/TPA Demand Mailing City Invalid Insurer/TPA Demand Mailing City. The
– Field 12, TIN Indicator I field contains a non-blank value but the TIN
Indicator was not equal to I. The TIN Indicator
is I and the Insurer/TPA Demand Mailing Name
is non-blank, but the Insurer/TPA Demand
Mailing City is missing or the field contains
characters other than alpha and special
characters A-Z, space, &, dash, @, #, /, comma,
semicolon, colon, period, quote.
TN15 Insurer/TPA Demand Mailing Invalid Insurer/TPA Demand Mailing State. The
State – Field 13, TIN Indicator I field contains a non-blank value but the TIN
Indicator was not equal to I. The TIN Indicator
is I and the Insurer/TPA Demand Mailing Name
is non-blank, but the Insurer/TPA Demand
Mailing State is missing or contained a value
other than a valid US postal state code.
TN16 Insurer/TPA Demand Mailing Zip Invalid Insurer/TPA Demand Mailing Zip. The
– Field 14, TIN Indicator I TIN Indicator is I and the Insurer/TPA Demand
Mailing Name is non-blank, but the Insurer/TPA
Demand Mailing Zip does not contain 5 numeric
digits followed by 4 spaces or 9 numeric digits.
Must be all zeroes or all spaces if the TIN
Indicator is not equal to I.
TN01 TIN – Field 1, TIN Indicator E, F, Invalid Employer TIN where the TIN Indicator
S or Z equals E, S, F or Z. TIN cannot be validated by
the BCRC. Must be a 9-digit numeric code. If
the TIN Indicator is not equal to Z, must be a
valid, IRS-assigned TIN. If you believe the TIN
to be valid, contact your EDI Representative to
supply supporting evidence. Your EDI
Representative will then update the system to
mark the TIN as valid and then you may resend
the record.
TN03 Name – Field 2, TIN Indicator E, Invalid or missing Employer Name received on
F, S or Z TIN Reference record where the TIN Indicator
equals E, S, F or Z. Field cannot be blank. It
must contain at least 2 characters. Special
characters other than, &, - ‘. @ # /: ; are not
allowed.
TN04 Address Line 1 – Field 3, TIN Invalid Employer Address Line 1 where the TIN
Indicator E, F, S or Z Indicator equals E, S, F, or Z. Employer Address
Line 1 field is missing or contains characters
other than alpha, numeric and special characters
A-Z, 0-9, space, &, dash, @, #, /, comma,
semicolon, colon, period, and quote. Must be
equal to all spaces if State Field 6 is equal to
‘FC’.

D-19
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

Error Code Field Description

TN05 Address Line 2 – Field 4, TIN Invalid Employer Address Line 2 where TIN
Indicator E, F, S, Z Indicator equals E, S, F or Z. If supplied,
Employer Address Line 2 must not contain
characters other than alpha, numeric and special
characters, A-Z, 0-9, space, &, dash, @, #, /,
comma, semicolon, colon, period, quote. Must
be equal to all spaces if State Field 6 is equal to
‘FC’.
TN06 City – Field 5, TIN Indicator E, F, Invalid Employer City where TIN Indicator
S or Z equals E, S, F or Z. Employer City is missing or
contains characters other than alpha, numeric
and special characters A-Z, 0-9, space, &, dash,
@, #, /, comma, semicolon, colon, period, quote.
Must be equal to all spaces if State Field 6 is
equal to ‘FC’.
TN07 State – Field 6, TIN Indicator E, F, Invalid Employer State where TIN Indicator
S or Z equals E, S, F or Z. Employer State is missing or
contained a value other than a valid US postal
state code or ‘FC’. Cannot equal ‘FC’ if the TIN
Indicator equals F.
TN08 Zip Code – Field 7, TIN Indicator Invalid Employer Zip Code where the TIN
E, F, S, or Z Indicator equals E, S, F or Z. Employer Zip
Code field must contain 5 numeric digits or 9
numeric digits. Must be equal to all spaces or all
zeroes if State Field 6 is equal to ‘FC’.
TN17 Foreign Employer Address Lines Missing or invalid Foreign Employer Address
1-4 - Fields 15, 16, 17, 18, TIN Line 1-4 supplied where TIN Indicator equals E,
Indicator E, F, S or Z S, or Z. The State Field 6 contained the value
FC for Foreign Country, but the foreign address
lines 1-4 contained all spaces or non-
alphanumeric characters; or the state code
supplied was not FC and the Foreign Employer
Address Lines 1-4 were not equal to all spaces.
Must equal all spaces if TIN Indicator is F.
TN18 Fields 3-7, TIN Indicator ‘I’ Invalid insurer/TPA address where TIN
Indicator is ‘I’. The address supplied was
insufficient or missing components needed to
determine a unique match to the postal database.
TN19 Fields 3-7, TIN Indicator ‘I’ Invalid insurer/TPA address where TIN
Indicator is ‘I’. The address matches one to
which mail is undeliverable, such as a vacant
lot.
TN20 Fields 3-7, TIN Indicator ‘I’ Invalid insurer/TPA address where TIN
Indicator is ‘I’. The apartment number was not
found in the postal database or was not supplied
for an address that requires apartment number.
TN21 Fields 3-7, TIN Indicator ‘I’ Invalid insurer/TPA address where TIN
Indicator is ‘I’. The house number or box
number was not found on the street.

D-20
GHP User Guide Appendix D: Disposition, Error, and Compliance Codes

Error Code Field Description

TN22 Fields 3-7, TIN Indicator ‘I’ Invalid insurer/TPA address where TIN
Indicator is ‘I’. The street name was not found
in the ZIP Code.
TN23 Fields 3-7, TIN Indicator ‘I’ Invalid insurer/TPA address where TIN
Indicator is ‘I’. The ZIP Code was not found in
the postal database.
TN24 Fields 9 – 14, TIN Indicator ‘I’ Invalid insurer/TPA demand address where TIN
Indicator is ‘I’. The address supplied was
insufficient or missing components needed to
determine a unique match to the postal database.
TN25 Fields 9 – 14, TIN Indicator ‘I’ Invalid insurer/TPA demand address where TIN
Indicator is ‘I’. The address matches one to
which mail is undeliverable, such as a vacant
lot.
TN26 Fields 9 – 14, TIN Indicator ‘I’ Invalid insurer/TPA demand address where TIN
Indicator is ‘I’. The apartment number was not
found in the postal database or was not supplied
for an address that requires apartment number.
TN27 Fields 9 – 14, TIN Indicator ‘I’ Invalid insurer/TPA demand address where TIN
Indicator is ‘I’. The house number or box
number was not found on the street.
TN28 Fields 9 – 14, TIN Indicator ‘I’ Invalid insurer/TPA demand address where TIN
Indicator is ‘I’. The street name was not found
in the ZIP Code.
TN29 Fields 9 – 14, TIN Indicator ‘I’ Invalid insurer/TPA demand address where TIN
Indicator is ‘I’. The ZIP Code was not found in
the postal database.
TN18 Fields 3-7, TIN Indicator ‘E’, ‘F’, Invalid employer address where TIN Indicator
‘S’, or ‘Z’ equals E, S, F or Z. The address supplied was
insufficient or missing components needed to
determine a unique match to the postal database.
TN19 Fields 3-7, TIN Indicator ‘E’, ‘F’, Invalid employer address where TIN Indicator
‘S’, or ‘Z’ equals E, S, F or Z. The address matches one to
which mail is undeliverable, such as a vacant
lot.
TN20 Fields 3-7, TIN Indicator ‘E’, ‘F’, Invalid employer where TIN Indicator equals E,
‘S’, or ‘Z’ S, F or Z. The apartment number was not found
in the postal database or was not supplied for an
address that requires apartment number.
TN21 Fields 3-7, TIN Indicator ‘E’, ‘F’, Invalid employer address where TIN Indicator
‘S’, or ‘Z’ equals E, S, F or Z. The house number or box
number was not found on the street.
TN22 Fields 3-7, TIN Indicator ‘E’, ‘F’, Invalid employer address where TIN Indicator
‘S’, or ‘Z’ equals E, S, F or Z. The street name was not
found in the ZIP Code.
TN23 Fields 3-7, TIN Indicator ‘E’, ‘F’, Invalid employer address received on TIN
‘S’, or ‘Z’ Reference record where TIN Indicator equals E,
S, F or Z. The ZIP Code was not found in the
postal database.

D-21
GHP User Guide Appendix E: MMSEA Section 111 Statutory Language

Appendix E MMSEA Section 111 Statutory Language

The Medicare Secondary Payor Mandatory Reporting Provisions
Of Section 111 of the Medicare, Medicaid, and SCHIP Extension Act of 2007
(See 42 U.S.C. 1395y(b)(7)&(b)(8))
SECTION 111 – MEDICARE SECONDARY PAYOR
(a) In General - Section 1862(b) of the Social Security Act (42 U.S.C. 1395y(b)) is
amended by adding at the end the following new paragraphs:
(7) REQUIRED SUBMISSION OF INFORMATION BY GROUP HEALTH
PLANS-
(A) REQUIREMENT- On and after the first day of the first calendar
quarter beginning after the date that is 1 year after the date of the
enactment of this paragraph, an entity serving as an insurer or third
party administrator for a group health plan, as defined in paragraph
(1)(A)(v), and, in the case of a group health plan that is self-insured
and self-administered, a plan administrator or fiduciary, shall--
(i) secure from the plan sponsor and plan participants such
information as the Secretary shall specify for the purpose of
identifying situations where the group health plan is or has
been --
(I) a primary plan to the program under this title; or
(II) for calendar quarters beginning on or after January 1, 2020,
a primary payer with respect to benefits relating to
prescription drug coverage under part D; and
(ii) submit such information to the Secretary in a form and manner
(including frequency) specified by the Secretary.
(B) ENFORCEMENT-
(i) IN GENERAL- An entity, a plan administrator, or a fiduciary
described in subparagraph (A) that fails to comply with the
requirements under such subparagraph shall be subject to a
civil money penalty of $1,000 for each day of noncompliance
for each individual for which the information under such
subparagraph should have been submitted. The provisions of
subsections (e) and (k) of section 1128A shall apply to a civil
money penalty under the previous sentence in the same manner
as such provisions apply to a penalty or proceeding under
section 1128A(a). A civil money penalty under this clause shall
be in addition to any other penalties prescribed by law and in
addition to any Medicare secondary payer claim under this title
with respect to an individual.
(ii) DEPOSIT OF AMOUNTS COLLECTED- Any amounts
collected pursuant to clause (i) shall be deposited in the Federal
Hospital Insurance Trust Fund under section 1817.

E-1
GHP User Guide Appendix E: MMSEA Section 111 Statutory Language

(C) SHARING OF INFORMATION- Notwithstanding any other provision

of law, under terms and conditions established by the Secretary, the
Secretary--
(i) shall share information on entitlement under Part A and
enrollment under Part B under this title with entities, plan
administrators, and fiduciaries described in subparagraph (A);
(ii) may share the entitlement and enrollment information
described in clause (i) with entities and persons not described
in such clause; and
(iii)may share information collected under this paragraph as
necessary for purposes of the proper coordination of benefits.
(D) IMPLEMENTATION- Notwithstanding any other provision of law,
the Secretary may implement this paragraph by program instruction or
otherwise.
(8) REQUIRED SUBMISSION OF INFORMATION BY OR ON BEHALF OF
LIABILITY INSURANCE (INCLUDING SELF-INSURANCE), NO FAULT
INSURANCE, AND WORKERS' COMPENSATION LAWS AND PLANS-
(A) REQUIREMENT- On and after the first day of the first calendar
quarter beginning after the date that is 18 months after the date of the
enactment of this paragraph, an applicable plan shall—
(i) determine whether a claimant (including an individual whose
claim is unresolved) is entitled to benefits under the program
under this title on any basis; and
(ii) if the claimant is determined to be so entitled, submit the
information described in subparagraph (B) with respect to the
claimant to the Secretary in a form and manner (including
frequency) specified by the Secretary.
(B) REQUIRED INFORMATION- The information described in this
subparagraph is—
(i) the identity of the claimant for which the determination under
subparagraph (A) was made; and
(ii) such other information as the Secretary shall specify in order to
enable the Secretary to make an appropriate determination
concerning coordination of benefits, including any applicable
recovery claim.
(C) TIMING- Information shall be submitted under subparagraph (A)(ii)
within a time specified by the Secretary after the claim is resolved
through a settlement, judgment, award, or other payment (regardless of
whether or not there is a determination or admission of liability).
(D) CLAIMANT- For purposes of subparagraph (A), the term 'claimant'
includes—

E-2
GHP User Guide Appendix E: MMSEA Section 111 Statutory Language

(i) an individual filing a claim directly against the applicable plan;

and
(ii) an individual filing a claim against an individual or entity
insured or covered by the applicable plan.
(E) ENFORCEMENT—
(i) IN GENERAL—An applicable plan that fails to comply with
the requirements under subparagraph (A) with respect to any
claimant shall be subject to a civil money penalty of $1,000 for
each day of noncompliance with respect to each claimant. The
provisions of subsections (e) and (k) of section 1128A shall
apply to a civil money penalty under the previous sentence in
the same manner as such provisions apply to a penalty or
proceeding under section 1128A(a). A civil money penalty
under this clause shall be in addition to any other penalties
prescribed by law and in addition to any Medicare secondary
payer claim under this title with respect to an individual.
(ii) DEPOSIT OF AMOUNTS COLLECTED- Any amounts
collected pursuant to clause (i) shall be deposited in the Federal
Hospital Insurance Trust Fund.
(F) APPLICABLE PLAN—In this paragraph, the term `applicable plan'
means the following laws, plans, or other arrangements, including the
fiduciary or administrator for such law, plan, or arrangement:
(i) Liability insurance (including self-insurance).
(ii) No fault insurance.
(iii)Workers' compensation laws or plans.
(G) SHARING OF INFORMATION—The Secretary may share
information collected under this paragraph as necessary for purposes
of the proper coordination of benefits.
(H) IMPLEMENTATION—Notwithstanding any other provision of law,
the Secretary may implement this paragraph by program instruction or
otherwise.
(b) Rule of Construction—Nothing in the amendments made by this section shall be
construed to limit the authority of the Secretary of Health and Human Services to
collect information to carry out Medicare secondary payer provisions under title
XVIII of the Social Security Act, including under parts C and D of such title.
(c) Implementation—For purposes of implementing paragraphs (7) and (8) of section
1862(b) of the Social Security Act, as added by subsection (a), to ensure appropriate
payments under title XVIII of such Act, the Secretary of Health and Human Services
shall provide for the transfer, from the Federal Hospital Insurance Trust Fund
established under section 1817 of the Social Security Act (42 U.S.C. 1395i) and the
Federal Supplementary Medical Insurance Trust Fund established under section 1841
of such Act (42 U.S.C. 1395t), in such proportions as the Secretary determines

E-3
GHP User Guide Appendix E: MMSEA Section 111 Statutory Language

appropriate, of $35,000,000 to the Centers for Medicare & Medicaid Services

Program Management Account for the period of fiscal years 2008, 2009, and 2010.

E-4
GHP User Guide Appendix F: MMSEA Section 111 Defs and Reporting Responsibilities

Appendix F MMSEA Section 111 Definitions and Reporting

Responsibilities
Attachment A – Definitions and Reporting Responsibilities
(Attachment A to the Supporting Statement for the MMSEA Section 111 Paperwork
Reduction Act (PRA) Federal Register (FR) Notice published February 13, 2009.)
SUPPORTING DOCUMENT FOR PRA PACKAGE FOR MEDICARE SECONDARY
PAYER REPORTING RESPONSIBILITIES FOR SECTION 111 OF THE MEDICARE,
MEDICAID, AND SCHIP EXTENSION ACT OF 2007.
Note: The second paragraph under Liability Self-Insurance was revised subsequent to the initial
publication of this Attachment on August 1, 2008.
DEFINITIONS AND REPORTING RESPONSIBILITIES
GROUP HEALTH PLAN (GHP) ARRANGEMENTS (42 U.S.C. 1395y(b)(7)).
INSURER
For purposes of the reporting requirements at 42 U.S.C.1395y(b)(7), an insurer is an entity that,
in return for the receipt of a premium, assumes the obligation to pay claims described in the
insurance contract and assumes the financial risk associated with such payments. In instances
where an insurer does not process GHP claims but has a third-party administrator (TPA) that
does, the TPA has the responsibility for the reporting requirements at 42 U.S.C. 1395y(b)(7).
THIRD PARTY ADMINISTRATOR (TPA)
For purposes of the reporting requirements at 42 U.S.C.1395y(b)(7), a TPA is an entity that pays
and/or adjudicates claims and may perform other administrative services on behalf of GHPs (as
defined at 42 U.S.C. 1395y(b)(1)(A)(v)), the plan sponsor(s) or the plan insurer. A TPA may
perform these services for, amongst other entities, self-insured employers, unions, associations,
and insurers/underwriters of such GHPs. If a GHP is self-funded and self-administered for
certain purposes but also has a TPA as defined in this paragraph, the TPA has the responsibility
for the reporting requirements at 42 U.S.C. 1395y(b)(7).

F-1
GHP User Guide Appendix F: MMSEA Section 111 Defs and Reporting Responsibilities

USE OF AGENTS FOR PURPOSES OF THE REPORTING REQUIREMENTS AT 42

U.S.C. 1395y(b)(7):
For purposes of the reporting requirements at 42 U.S.C. 1395y(b)(7), agents may submit reports
on behalf of :
• Insurers for GHPs
• TPAs for GHPs
• Employers with self-insured and self-administered GHPs
Accountability for submitting the reports in the manner and form stipulated by the Secretary and
the accuracy of the submitted information continues to rest with each of the above-named
entities.
The CMS will provide information on the format and method of identifying agents for reporting
purposes.
LIABILITY INSURANCE (INCLUDING SELF-INSURANCE), NO-FAULT
INSURANCE, AND WORKERS’ COMPENSATION (42 U.S.C. 1395y(b)(8)) – INSURER.
For purposes of the reporting requirements for 42 U.S.C. 1395y(b)(8), a liability insurer (except
for self-insurance) or a no-fault insurer is an entity that, in return for the receipt of a premium,
assumes the obligation to pay claims described in the insurance contract and assumes the
financial risk associated with such payments. The insurer may or may not assume responsibility
for claims processing; however, the insurer has the responsibility for the reporting requirements
at 42 U.S.C. 1395y(b)(8) regardless of whether it uses another entity for claim processing.
CLAIMANT:
For purposes of the reporting requirements at 42 U.S.C. 1395y(b)(8), “claimant” includes: 1) an
individual filing a claim directly against the applicable plan, 2) an individual filing a claim
against an individual or entity insured or covered by the applicable plan, or 3) an individual
whose illness, injury, incident, or accident is/was at issue in “1)” or “2)”.
APPLICABLE PLAN:
For purposes of the reporting requirements at 42 U.S.C. 1395y(b)(8), the “applicable plan” as
defined in subsection (8)((F) has the responsibility for the reporting requirements at 42 U.S.C.
1395y(b)(8). For workers’ compensation information this would be the Federal agency, the State
agency, or self-insured employer or the employer’s insurer.

F-2
GHP User Guide Appendix F: MMSEA Section 111 Defs and Reporting Responsibilities

NO-FAULT INSURANCE:
Trade associations for liability insurance, no-fault insurance and workers’ compensation have
indicated that the industry’s definition of no-fault insurance is narrower than CMS’ definition.
For purposes of the reporting requirements at 42 U.S.C. 1395y(b)(8), the definition of no-fault
insurance found at 42 C.F.R. 411.50 is controlling.
LIABILITY SELF-INSURANCE:
42 U.S.C. 1395y(b)(2)(A) provides that an entity that engages in a business, trade or profession
shall be deemed to have a self-insured plan if it carries its own risk (whether by a failure to
obtain insurance, or otherwise) in whole or in part. Self-insurance or deemed self-insurance can
be demonstrated by a settlement, judgment, award, or other payment to satisfy an alleged claim
(including any deductible or co-pay on a liability insurance, no-fault insurance, or workers’
compensation law or plan) for a business, trade or profession. See also 42 C.F.R. 411.50.
Where an entity engages in a business, trade, or profession, deductible amounts are self-
insurance for MSP purposes. However, where the self-insurance in question is a deductible, and
the insurer is responsible for Section 111 reporting with respect to the policy, it is responsible for
reporting both the deductible and any amount in excess of the deductible.
WORKERS’ COMPENSATION LAW OR PLAN
For purposes of the reporting requirements at 42 U.S.C. 1395y(b)(8), a workers’ compensation
law or plan means a law or program administered by a State (defined to include commonwealths,
territories and possessions of the United States) or the United States to provide compensation to
workers for work-related injuries and/or illnesses. The term includes a similar compensation plan
established by an employer that is funded by such employer directly or indirectly through an
insurer to provide compensation to a worker of such employer for a work-related injury or
illness.
USE OF AGENTS FOR PURPOSES OF THE REPORTING REQUIREMENTS AT 42 U.S.C.
1395y(b)(8):
Agents may submit reports on behalf of:
• Insurers for no-fault or liability insurance
• Self-insured entities for liability insurance
• Workers’ compensation laws or plans
Accountability for submitting the reports in the manner and form stipulated by the Secretary and
the accuracy of the submitted information continues to rest with each of the above-named
entities.
TPAs of any type (including TPAs as defined for purposes of the reporting requirements at 42
U.S.C. 1395y(b)(7) for GHP arrangements) have no reporting responsibilities for purposes of the
reporting requirements at 42 U.S.C. 1395y(b)(8) for liability insurance (including self-
insurance), no-fault insurance, or workers’ compensation. Where an entity reports on behalf of
another entity required to report under 42 U.S.C. 1395y(b)(8), it is doing so as an agent of the
second entity.
CMS will provide information on the format and method of identifying agents for reporting
purposes.

F-3
GHP User Guide Appendix G: Reporting Employer Size

Appendix G Reporting Employer Size

Reporting Employer Size
This appendix is intended as an overview of the MSP regulations related to employer size
and how they affect Section 111 reporting. However, RREs must refer to 42 C.F.R. Part
411.101 and 42 C.F.R. Part 411.170 for details on the calculation of employer size.
Additional information can be found in Chapter 1 of the CMS MSP Manual at
https://www.cms.gov/manuals/downloads/msp105c01.pdf. All Medicare manuals can be
found at https://www.cms.gov/Regulations-and-Guidance/Guidance/Manuals/Internet-Only-
Manuals-IOMs.html. The MSP Manual is shown as publication 100-05 on that page. Also
refer to Section 7.2.4 and the Small Employer Exception page on the CMS Website at
https://www.cms.gov/Medicare/Coordination-of-Benefits-and-
Recovery/EmployerServices/Small-Employer-Exception.html for an explanation of a related
Small Employer Exception (SEE).
MSP regulations for beneficiaries entitled to Medicare due to age or disability require
information on employer size to determine the correct primary payer. Employer size is not a
factor if the beneficiary is entitled to Medicare due to ESRD. Employer size is based on the
number of employees during specified time periods, not the number of individuals covered
under the GHP. When calculating the number of employees, RREs should use the total
number of employees in an organizational structure (parent, subsidiaries and siblings) rather
than just the number of employees in the particular subsidiary being reported on. Subsidiaries
of foreign companies must count the number of employees in the organization worldwide. If
the employer is part of a multi-employer/multiple employer plan, this field should reflect the
size of the largest employer in the plan.
Employer size is reported using the Employer Size indicator in Field 16 on the MSP Input
File Detail Record. The Employer Size indicator values reflect categories that are based on
MSP regulations related to the number of employees during a specific time period which
affect whether Medicare is the secondary payer in conjunction with the reason an individual
is entitled to Medicare (age and disability). A value of ‘0’ is used to report an employer size
of 1 to 19 employees, ‘1’ is used for 20 to 99 employees and ‘2’ for 100 or more employees.
RREs must follow the MSP regulations when determining employer size. It is not just a
count of employees as of the current reporting date. The employer size reported for GHP
coverage on an MSP Input Detail Record is associated with the coverage dates being
reported, not the actual date you are submitting your files. If you are reporting a coverage
period starting in 2019, you need to look at the number of employees during 2018 and then
keep track of changes throughout 2019. The employer size is reported according to the dates
of coverage for the individuals and what the employer size indicator is calculated to be
during those dates of coverage.
Reporting a change in employer size is not as simple as just reporting the effective date of
when the actual number of employees changed. It is to be reported with effective dates
according to MSP regulations regarding when the change affects whether Medicare could be
primary or secondary as explained below.
Working Aged Provisions
Medicare benefits are secondary to benefits payable under GHPs for individuals age 65 or
over who have GHP coverage as a result of their own current employment status with an
G-1
GHP User Guide Appendix G: Reporting Employer Size

employer that has 20 or more employees; or the current employment status of a spouse of any
age with such an employer. These individuals are known as the “working aged”. Medicare is
the secondary payer to GHPs for the working aged where either: a single employer of 20 or
more full and/or part-time employees is the sponsor of the GHP or contributor to the GHP, or
two or more employers are sponsors or contributors to a multi-employer/multiple employer
plan, and a least one of the employers has 20 or more full and/or part-time employees.
The 20 or more employee requirement is met if the employer employed 20 or more full
and/or part-time employees for each working day in each of 20 or more calendar weeks in the
current or preceding year. So, when the number of employees first equals 20 or more, a
change to employer size is not immediately submitted. The change in employer size is
not reported until the date the employer has had 20 or more employees for 20 or more
weeks in a calendar year. The effective date of the employer size change would be the
first day of the 20th week that the employer has had 20 or more employees in a
calendar year. Note that the 20 weeks do not have to be consecutive. A change that
involves employer size increasing to 20 or more employees is likely to occur mid-year or
later. The requirement is based on the number of employees, not the number of people
covered under the plan. Employers who did not meet the requirement during the previous
calendar year may meet it at some point during the new calendar year, and at that point
Medicare would become the secondary payer for the remainder of that year and through
the next year even if the number of employees subsequently drops below 20.
When employer size shrinks to less than 20 employees, the earliest Medicare could become
primary is January 1 of the following year. There is no “20 week rule” for employers that get
smaller. There is not a scenario where an RRE would submit a change to lower employer size
with an effective date of anything other than January 1st.
Working Aged - Example 1:
Assume an employer employed 20 or more employees for all of 2006. For the years 2007
and 2008, the employer always had fewer than 20 employees. For the first 6 months of
2009, the employer employed 20 or more employees.
Medicare would be the secondary payer to GHP coverage during all of calendar year
2007 because there were 20 or more employees during the preceding year, 2006.
Medicare would be primary to GHP coverage in 2008 because the employer had fewer
than 20 employees during 2008 and fewer than 20 in the preceding year of 2007.
Medicare would be the primary payer for the first 19 weeks of 2009 based on the number
of employees during 2008. Starting week 20 of 2009, Medicare would become secondary
and remain secondary for the remainder of 2009. Since the employer employed 20 or
more employees for more than 20 weeks in 2009, Medicare will also be secondary for all
of 2010.
For this example, we chose not to list an employee count for the year 2005 Therefore, it
is unknown if Medicare was primary or secondary for the first 19 weeks of 2006.
Working Aged – Example 2:
On the flip side, assume an employer employed 20 or more employees for all of 2006.
For the years 2007 and 2008, the employer always had 20 or more employees. Medicare
would be the secondary payer during all of calendar years 2007 and 2008 because there
were 20 or more employees during the preceding years, 2006 and 2007 respectively.

G-2
GHP User Guide Appendix G: Reporting Employer Size

For the first 6 months of 2009, the employer employed less than 20 employees. Since
there is no “20 week rule” for employers that get smaller, Medicare will not become the
primary payer over GHP coverage until January 1, 2010. Medicare will remain primary
payer in 2010 until the employer employs more than 20 employees for more than 20
calendar weeks in the current year. Remember, the 20 weeks do not have to be
consecutive. Medicare will become secondary payer as soon as the 20-employee, for 20
weeks threshold is met.
For this example, we chose not to list an employee count for the year 2005. Therefore, it
is unknown if Medicare is primary or secondary for the first 19 weeks of 2006.
Working Aged – Example 3:
Assume an employer has 20 employees for all of 2008 and for 21 weeks at the start of
2009. That means Medicare will be secondary to GHP coverage in all of 2009 and all of
2010. If the employer went down to 15 employees for the 31 remaining weeks of 2009
and all of 2010, nothing changes. Medicare is still secondary to GHP coverage for all of
2009 and 2010. However, starting on January 1, 2011, Medicare would be primary for at
least the first 19 weeks of 2011 since the employer did not have 20 or more employees
for 20 or more weeks in 2010.
Disability Provisions
Medicare is the secondary payer for claims for beneficiaries under age 65 who have
Medicare because of a disability and who are covered under a Large Group Health Plan
(LGHP) through their current employment or through the current employment of any family
member. An LGHP is a GHP that covers employees of either: a single employer or employee
organization that employed at least 100 full-time or part-time employees on 50 percent or
more of its regular business days during the previous calendar year; or two or more
employers or employee organizations where at least one employed at least 100 full-time or
part-time employees on 50 percent or more of its regular business days during the previous
calendar year. Medicare is the secondary payer of benefits if a single employer employs 100
or more employees or if the GHP is a multi-employer/multiple employer plan that covers one
employer that employs 100 or more full and/or part-time employees.
The 100 employee or more requirement is met if the employer employed 100 or more
employees on 50% or more of its business days in the previous calendar year. Therefore, the
employer size changes related to 100 or more employees can only occur effective Jan 1st
and depends on the number of employees throughout the previous calendar year.
Disability - Example 4:
Assume an employer employed 100 or more employees in both 2006 and 2007. In 2008,
the employer had fewer than 100 employees for 75% of its business days and in 2009,
employment increased to over 100 employees for more than 50% of its business days.
Medicare would be the secondary payer to GHP coverage in 2007 because the employer
had 100 or more employees during 2006. Medicare would be secondary to the GHP
coverage during 2008 because in 2007 the employer met or exceeded 100 employees for
the entire year. Medicare would be primary payer for all of 2009 because the employer
employed fewer than 100 employees for more than 50% of its business days in 2008.
Medicare will be secondary for all of 2010 because the employer again had 100 or more
employees on more than 50% of its business days in 2009. Please note that the MSP

G-3
GHP User Guide Appendix G: Reporting Employer Size

status for 2006 is dependent upon the number of employees employed in year 2005,
which is why the MSP status of 2006 is not mentioned in this example.
Setting the Employer Size Indicator
It is recommended that RREs obtain employer size information from employers on at least a
yearly basis. This information must include enough detail for the RRE to make the employer
size determination according to the MSP regulations (20 or more employees for 20 weeks or
more in the current or previous calendar year and 100 or more employees for 50% or more of
the employer’s business days in the previous calendar year). So, an RRE needs to retain
employee counts or changes to those counts by employer, by business day, by calendar week,
and by calendar year in its internal systems database. Then the employer size indicator must
be calculated and stored by specific date ranges that apply to GHP coverage dates. When
GHP coverage is reported, the employer size indicator associated with the specific GHP
coverage dates must be reported on the record. If the employer size indicator has different
values during the span of the GHP coverage dates to be reported, multiple MSP Input File
records must be submitted to reflect that.
On January 1st, the Employer Size indicator could be determined by the following series of
checks:
• If the employer had 100 or more employees during the prior calendar year for 50% or
more of the employer’s business days, then set the indicator to ‘2’
• Otherwise, if the employer had between 20 and 99 employees for 20 or more weeks
in the prior calendar year, then set the indicator to ‘1’
• Otherwise, if the employer did not have 20 or more employees for at least 20 weeks
in the prior calendar year, then set the indicator to ‘0’
If the indicator is different than what was previously reported, then submit the appropriate
update and add transactions to reflect the change in size as will be described below.
Remember that the Employer Size indicator for a multi-employer/multiple employer plan is
based on the largest employer in the plan.
In addition, RREs must inform employers that they are responsible for notifying the RRE of
any changes that occur during the course of a calendar year that could impact the employer
size determination related to the 20 employee or more requirement described previously. In
other words, the employer must notify the RRE when they have increased to a size of 20 or
more employees for 20 or more weeks during the current calendar year so that the RRE can
submit the appropriate changes for GHP coverage dates affected by the change in a timely
manner for Section 111 reporting.
Again note:
• an increase in size to 20 or more employees is effective as soon as the employer
reached 20 employees for at least 20 weeks during the current calendar year
• a decrease in size to less than 20 employees could only be effective as of January 1st
• an increase in size from less than 100 employees to 100 or more employees can only
be effective as of January 1st
• a decrease in size from 100 or more employees to less than 100 employees can only
be effective as of January 1st

G-4
GHP User Guide Appendix G: Reporting Employer Size

If an RRE is unable to obtain the employer size related to a GHP in order to report timely, the
Employer Size should be defaulted to a value of ‘2’ (100 or more employees) and then later
corrected with Update records as needed when an accurate size can be calculated. The
importance of employer cooperation with data collection by RREs for Section 111 is
documented in the “Alert to Employers” that can be found as a download on the Mandatory
Insurer Reporting for Group Health Plans (GHP) page of https://go.cms.gov/mirghp. It is in
each employer’s best interest to provide accurate employer size to Insurer and TPA RREs in
a timely manner to comply with MSP regulations, reduce coordination of benefits costs and
reduce the number of possible recovery actions that could be made against them.
Reporting Changes in Employer Size
Employer size changes must be reported in a manner slightly different than most other
changes that are reported. For example, when an employee retires, the termination date on
the update transaction submitted reflects the actual day the employee retired. When employer
size changes occur, the termination date generally will be later than the date the actual
employer size change occurred. The termination date is later because of the way the
Medicare regulations work. When employer size changes, RRE’s will need to determine if
the change in size impacts the order in which benefits should be paid. If Medicare is
becoming primary or secondary under either the Working Aged or Disability provisions,
update transactions for all affected Active Covered Individuals must be submitted which
reflect the date when the 20 employee or more for 20 or more weeks requirement or the 100
employee or more for 50% or more of the business days in the previous calendar year (Jan
1st) requirement is actually reached. First, the date of the employer size indicator change is
determined and then that is applied to any GHP coverage records open at that time.
If the employer size indicator changes from less than 20 employees to 20 or greater or the
employer size indicator changes from less than 100 employees to 100 or greater, any
previously reported records accepted with a ‘01’ disposition code must have an update
transaction submitted to terminate the existing record and an add transaction must be
submitted to reflect the new employer size indicator. The effective date of the GHP coverage
on the Add record is set to the date the employer size indicator changed. If employer size
indicator changes from 20 employees or greater to less than 20 or employer size decreases
from 100 employees or greater to less than 100, any previously reported records previously
accepted with a ‘01’ disp code must have an update transaction submitted to terminate the
existing record and an add transaction must be submitted to reflect the new employer size
indicator. The effective date used in the add transaction is not the date the employer size
change actually occurred but rather it must be equal to the date Medicare becomes secondary
under the Working Aged or Disability provisions if employer size is increasing, or the date
Medicare becomes primary under the Working Aged or Disability provisions if employer
size is decreasing. The Termination Date used will always be the day before the Effective
Date as calculated for the change in the employer size indicator.
When RREs are creating their initial files for Section 111 reporting, they must report
coverage retroactively back to January 1, 2009. If there are changes to employer size
indicator from this date to the current reporting timeframe, an RRE may need to send
multiple Add records with associated Effective and Termination Dates on the initial file for
one individual to reflect different categories of employer size during the coverage period if
applicable. In addition, the first time you report on an Active Covered Individual you may
have to report multiple records of GHP coverage if there are multiple associated employer
size indicators for the coverage period being reported.
G-5
GHP User Guide Appendix G: Reporting Employer Size

Other notes:
• Throughout this explanation of reporting employer size and the examples provided,
we have stressed that the RRE needs only submit Update records reflecting the last
day of a particular employer size indicator in the termination date for records
previously accepted with a ‘01’ disposition code. In most cases, when an RRE
submits a record reflecting coverage for a Medicare beneficiary entitled to Medicare
due to age with an Employer Size of ‘0’, the record will be returned with an ‘SP’
disposition code and the SPES error code since Medicare is primary, not secondary,
and the BCRC did not create an MSP occurrence. Likewise, if the Medicare
beneficiary is entitled due to disability and the Employer Size reported is ‘0’ or ‘1’, a
disposition code of ‘SP’ and the error code of SPES will be returned. If the Employer
Size indicator value increases, RREs are required to send Add records for these
individuals again even though they were previously sent and rejected. The new Add
records should reflect the new Employer Size indicator and the Effective Date should
be reported as the later of the change to the Employer Size indicator or the
individual’s GHP effective date. The reason for a Medicare beneficiary’s entitlement
may change so it is recommended that at the point of an employer size indicator
change, the RRE resubmit previously rejected Add records for all Active Covered
Individuals that are Medicare beneficiaries for reconsideration of MSP.
• In general, Effective Dates (Field 10) reported on all Add records should reflect the
later of the effective date of the Active Covered Individual’s GHP coverage and the
effective date of the employer size indicator.
• As stated elsewhere in this guide, RREs are only required to report Active Covered
Individuals that are Medicare beneficiaries on the MSP Input File. RREs may either
use the definition of Active Covered Individuals and the associated age thresholds to
report; or query Active Covered Individuals first and only report those that are found
to be Medicare beneficiaries.
Reporting an Employer Size Change – Example 5:
An employer had 40 employees for all of 2009. The RRE submitted Add records for the
employees and dependents that were Active Covered Individuals and Medicare
beneficiaries and 5 of these records received a ‘01’ disposition code meaning that the
BCRC created MSP occurrences for them to indicate that Medicare was the secondary
payer. All of these individuals were entitled to Medicare due to age (worked aged).
During 2009, this employer employed 20 or more employees for the entire year. Based
upon the fact that the employer employed 20 or more employees for all of 2009, we know
that the GHP will be the primary payer of benefits under the Working Aged provision for
GHP coverage in all of 2010. On these original Add records, the employer size was
submitted with a value equal to ‘1’ meaning 20 to 99 employees.
On 1/31/2010, the employer terminated 25 employees, making their total number of
employees 15. If these terminations ended the GHP coverage for any of the individuals
for whom records were previously submitted and accepted with a ‘01’ disposition code,
the RRE must submit Update records for them on their next quarterly update MSP Input
File with the corresponding Termination Date. The update transaction should include the
following data elements: the Transaction Type = 2 (Update), the Employer Size = 1 (the
value entered on original submission), the Termination Date = 01/31/2010, the last day of
GHP coverage prior to the termination. All other fields should match the values that were
G-6
GHP User Guide Appendix G: Reporting Employer Size

sent on the original Add record. No further reporting will be required on these individuals
since they are now not considered Active Covered Individuals unless their status changes
at a later date.
Since the GHP remains the primary payer under the Working Aged provision for the
remainder of calendar year 2010, the employer size indicator remains the same and an
update transaction should not be submitted for the remaining Active Covered Individuals
until the employer size indicator is re-evaluated as of 1/1/2011. At this point, the RRE
will determine how many employees were employed for at least 20 weeks during the
calendar year and submit any required update transactions to reflect changes made to the
employer size indicator.
On 1/1/2011, the RRE determined that the number of employees for this employer
remained under 20 for the remainder of 2010. Since the employer did not employ 20 or
more employees for 20 or more weeks in 2010 (the prior calendar year) or yet in 2011
(the current calendar year), Medicare is primary to the GHP under the Working Aged
provision starting 1/1/2011. Therefore, the effective date of the change in employer size
is 1/1/2011 (not 1/31/2010). The employer size indicator changes to ‘0’ as of 1/1/2011.
The RRE should submit update transactions for any of the Active Covered Individuals for
whom GHP coverage continues and whose records were previously submitted and
accepted with a ‘01’ disposition code on their next quarterly update MSP Input File.
The update transaction should include the following data elements:
• Transaction Type = ‘2’ (update)
• Employer Size = ‘1’ (the value entered on original Add record)
• Termination Date = 12/31/2010 (the last day that the GHP was the primary payer
or the last day the employer size indicator was calculated to be 20-99 employees)
• All other fields should match the values that were sent on the original Add record.
The RRE should also submit add transactions for these same individuals and any new
Active Covered Individuals to report the change in the employer size indicator effective
1/1/2011. The add transaction should include the following data elements:
• Transaction Type = ‘0’ (add)
• Employer Size = ‘0’ (the new value - employer with 1-19 employees), the
Effective Date = 1/1/2011 (the date the new employer size indicator change
became effective)
• All other fields should be submitted with the RRE’s most current information.
Most of these Add records are likely to be returned with an ‘SP’ disposition code and
error of ‘SPES’ if the beneficiaries are entitled to Medicare due to age or disability due to
the new employer size of less than 20 employees. However, it is advisable to submit
these records just in case the reason for entitlement for any of these individuals has
changed.
Reporting an Employer Size Change – Example 6:
In early 2010, an RRE submitted Add records for all of the Active Covered Individuals
who were Medicare beneficiaries covered by a certain employer GHP, which were
accepted by the BCRC and returned with a ‘01’ disposition code. The employer had 80
employees for all of 2009 so when the Add records were submitted, the Employer Size

G-7
GHP User Guide Appendix G: Reporting Employer Size

field was submitted with a value of ‘1’ on each record meaning 20 to 99 employees. The
GHP for the employer was not a multi-employer or multiple employer plan, thus the GHP
was the primary payer of benefits under the Working Aged provisions and Medicare was
the primary payer of benefits under the Disability provisions of MSP. On 1/1/2011, the
RRE determined that the number of employees for this employer remained 80 for all of
2010. Since Medicare remains the primary payer of benefits under the Disability
provisions of MSP and the GHP remains the primary payer under the Working Aged
provisions, no change is made to the employer size indicator as of 1/1/2011 and therefore
no update transactions are required to previously posted records.
On November 1, 2011, the employer purchased another company that had 30 employees.
With the purchase, the total number of employees at the company is 110. The new
employees were not eligible for GHP coverage. On 1/1/2012, the RRE calculated the
number of employees for the previous calendar year and determined that although the
company now has 100 or more employees, Medicare remains the primary payer of
benefits under the Disability provisions of MSP because the employer did not have 100
or more employees on 50% or more of its regular business days during the preceding
calendar year, 2011. No change is made to the employer size indicator as of 1/1/2012 and
no update transactions are required to previously posted records.
During calendar year 2012, no change was made to employer size. On 1/1/2013, the RRE
calculated the number of employees for the previous calendar year (2012) and determined
that the employer had 100 or more employees for all of 2012. The effective date of the
change to the employer size indicator is 1/1/2013 per MSP regulations, not 11/1/2011
when the new employees were actually added to the company. Therefore, for the records
previously submitted and accepted with a ‘01’ disposition code which reflect continuing
coverage under the GHP, the RRE must send both an update transaction and an add
transaction to report the change in the Employer Size field on their next Quarterly Update
MSP Input File. The update transaction would have a Termination Date of 12/31/2012,
the last day Medicare would be primary under the Disability provisions which is the last
day the employer size indicator was ‘1’. The add transaction would reflect an Effective
Date of 01/01/2013 and the Employer Size value submitted would be ‘2’ meaning 100 or
more employees. As of 01/01/2013, Medicare would be the secondary payer under the
Working Aged and Disability provisions of MSP. Both the update and add transactions
should be submitted on the first Quarterly Update MSP Input File in 2013.
The Update record for each affected record will include the following data elements:
• Transaction Type = ‘2’ (update)
• Employer Size = ‘1’ (the value entered on original submission)
• Termination Date = 12/31/2012 (the last day Medicare is primary under Disability
MSP)
• All other fields should match the values that were sent on the original record.
The Add record will include the following data elements:
• Transaction Type = ‘0’ (add)
• Employer Size = ‘2’ (the new value - used for an employer with 100 or more
employees)

G-8
GHP User Guide Appendix G: Reporting Employer Size

• Effective Date = 01/01/2013 (the first day the GHP is primary under the
Disability provisions of MSP. This is the day after the termination date of the
Update record and reflects when the employer size indicator changed to ‘2’.)
• All other fields should be submitted with the RRE’s most current information.
Reporting an Employer Size Change – Example 7:
Suppose an RRE previously submitted Add records for 40 Active Covered Individuals
who are Medicare beneficiaries for a particular GHP. On the original Add records, the
Employer Size was entered with a value of ‘1’ reflecting 20 to 99 employees. 39 of the
original Add records were accepted with a ‘01’ disposition code because these were
beneficiaries entitled to Medicare due to age. However, the Add record for Jane Smith
was rejected with an ‘SP’ disposition code and SPES error because Jane Smith was
entitled to Medicare due to Disability and the Employer Size reported is less than 100.
During 2009, this employer hired an additional 100 employees who were employed for
more than 50% of its business days in 2009. Based upon the fact that the employer
employed 100 or more employees for 50% or more of its regular business days in 2009,
we know that the GHP will now be the primary payer of benefits for Ms. Smith under the
Disability provision for her GHP coverage during all of 2010. The employer size
indicator changes from ‘1’ to ‘2’ as of 1/1/2010.
On the file submission for the First Quarter of 2010, the RRE should submit an Update
record for each of the 39 records previously accepted with a ‘01’ disposition code that is
still open (hasn’t already been updated with a Termination Date). An Update record is not
required for Ms. Smith because the original Add record that was submitted for her was
not accepted with a ‘01’ disposition code.
The Update records should include the following data elements:
• Transaction Type = ‘2’ (update)
• Employer Size = ‘1’ (the value entered on original submission)
• Termination Date = 12/31/2009
• All other fields should match the values that were sent on the original record.
The RRE should also submit add transactions for all of those 39 individuals previously
reported and accepted. These Add records will document the effective date of the new
Employer Size indicator. In addition, the RRE must submit Add records for any new
Active Covered Individuals that were added to the plan since the last file was submitted.
Lastly, the RRE should submit an Add record for Ms. Smith since she is still an Active
Covered Individual who is a Medicare beneficiary and now, due to the new Employer
Size indicator, her GHP coverage will be primary to Medicare. In other words, the RRE
should be submitting Add records for all Active Covered Individuals that are Medicare
beneficiaries to report the new value in the Employer Size indicator. These Add records
must have an effective date of 1/1/2010 which reflects when the employer size indicator
changed.
The Add records will include the following data elements:
• Transaction Type = ‘0’ (add)
• Employer Size = ‘2’ (the new value - used for an employer with 100 or more
employees)

G-9
GHP User Guide Appendix G: Reporting Employer Size

• Effective Date = 01/01/2010 (or for newly covered individuals, the effective date
of GHP coverage if later)
• All other fields should be submitted with the RRE’s most current information.
Reporting an Employer Size Change – Example 7a:
Given the same conditions as given in Example 7 directly above, suppose that one of the
new Active Covered Individuals for which the RRE needs to report in first quarter 2010
was hired November 23, 2009 and her GHP coverage was effective on that date
(11/23/2009). Also suppose the RRE’s file submission timeframe is the first week of the
second month of each quarter so a record for this individual was not submitted in the
RRE’s fourth quarter 2009 MSP Input File. When the RRE initially reports the GHP
coverage for this person in its first quarter 2010 MSP Input File, since the GHP coverage
to be reported for this person spans a period of time with two different employer size
indicators, two Add records must be submitted, one to reflect the employer size indicator
of ‘1’ for the coverage prior to 1/1/2010 and the other to reflect the employer size
indicator of ‘2’ for the coverage that continues 1/1/2010 and subsequent.
The first Add record will include the following data elements:
• Transaction Type = ‘0’ (add)
• Employer Size = ‘1’ (20 to 99 employees – the employer size indicator in effect
11/23/2009 - 12/31/2009)
• Effective Date = 11/23/2009 (start of the individual’s GHP coverage)
• Termination Date = 12/31/2009 (last date the employer size indicator of 1 applies)
The second Add record will include the following data elements:
• Transaction Type = ‘0’ (add)
• Employer Size = ‘2’ (100 or more – the employer size indicator in effect 1/1/2010
and subsequent)
• Effective Date = 1/1/2010 (effective date of the employer size indicator change)
Reporting an Employer Size Change – Example 8:
Suppose an RRE previously submitted Add records for 10 Active Covered Individuals for
a particular GHP with an Employer Size value equal to 0 meaning 1 to 19 employees.
This employer did not employ 20 or more employees for 20 or more weeks in 2008 so
Medicare must be primary to GHP coverage at the start of 2009. The BCRC determined
that Medicare is primary rather than secondary for the coverage reported on these 10 Add
records and returned an ‘SP’ disposition code and an SPES error code on each
corresponding response record.
On January 5th, 2009, this employer hired an additional 10 employees who worked for 20
or more calendar weeks in 2009. These weeks happened to be consecutive in this
example although that is not required under the 20 week rule. Starting week 20 of 2009
(May 18, 2009), the GHP became primary payer under the Working Aged provision and
remains primary for the remainder of GHP coverage in 2009 because the 20 or more
employee threshold was met as of this date. Remember, as soon as the 20-employee
threshold is met, Medicare becomes the secondary payer under the Working Aged
provision for the remainder of that year and through the next year. As of 5/18/2009, the
employer size indicator changes from a value of ‘0’ to a value of ‘1’.
G-10
GHP User Guide Appendix G: Reporting Employer Size

In the RRE’s second quarterly submission, they must submit add transactions for all
Active Covered Individuals in the plan. It is important that the Effective Dates reported
are 5/18/2009 or the effective date of a particular individual’s GHP coverage if that is
after 5/18/2009. This will ensure that the BCRC creates an MSP occurrence starting at
the date that Medicare becomes the secondary payer. Update records are not required
since no previously submitted record was accepted with a ‘01’ disposition code.
The Add records will include the following data elements:
• Transaction Type = ‘0’ (add)
• Employer Size = ‘1’ (the new value - used for an employer with 20-99
employees)
• Effective Date = 05/18/2009 (or the effective date of the individual’s GHP
coverage if later)
• All other fields should be submitted with the RRE’s most current information.
Initial Reporting When Employer Size Reaches 20 and Employer is Not Part of a Multi-
Employer/Multiple Employer Plan
As stated previously in this guide, if an employer has less than 20 full and/or part-time
employees as defined in 42 C.F.R. Part 411.101 and 42 C.F.R. Part 411.170, and the
employer is not part of a multi-employer/multiple employer GHP, then the covered
individuals under that plan do not have to be reported under Section 111 unless a covered
individual is receiving dialysis or has had a kidney transplant (ESRD). However, records for
all Active Covered Individuals in these plans may be submitted with the proper value in the
Employer Size (Field 16). If reported and the BCRC determines that MSP does not exist,
then an SPES error code will be returned as explained in Section 7.2.8.2 of this guide.
If coverage was not previously reported for any individuals due to the employer size being
less than 20 employees, and subsequently the number of employees increases to 20 or more,
the affected covered individuals must be reported on Add records if they meet the other
requirements to be included on the MSP Input File. When these Add records are submitted,
you must use the later of the effective date of the new employer size indicator or the
individual’s GHP coverage effective date in Field 10 (Effective Date) of the MSP Input File
Detail Record rather than simply the effective date of the individual’s GHP coverage. This
will ensure that the BCRC creates an MSP occurrence starting at the date that Medicare
becomes the secondary payer.

G-11
GHP User Guide Appendix H: Unsolicited MSP Response File Specifications

Appendix H Unsolicited MSP Response File Specifications

Unsolicited MSP Response File Header Record

Table H-1: Section 111 GHP Unsolicited MSP Response File Header Record - 600 bytes
Field Name Size Displacement Data Type Description
1. Header Type 4 1-4 Alpha-numeric Contains a value of ‘USOH'.
Code
2. RRE ID 9 5-13 Numeric Section 111 RRE ID.
3. File Type 4 14-17 Alpha-numeric Contains a value of ‘USOL'.
4. File Date 8 18-25 Numeric Date Date file created by the BCRC.
(CCYYMMDD format).
5. Filler 575 26-600 Alpha-numeric Not Used.
Filled with spaces.

H-1
GHP User Guide Appendix H: Unsolicited MSP Response File Specifications

Unsolicited MSP Response File Detail Record

Table H-2: Section 111 GHP Unsolicited MSP Response File Detail Record - 600 bytes
Field Name Size Displacement Data Type Description
1. Transaction 4 1-4 Alpha- ‘USOL’
Type numeric
2. Medicare ID 12 5-16 Alpha- Medicare ID (Health Insurance
numeric Claim Number [HICN] or
Medicare Beneficiary Identifier
[MBI])
Note: The Medicare ID is also
known as the Medicare Number
to CMS’ Medicare beneficiaries.
3. Beneficiary 6 17-22 Text First 6 characters of the
Surname beneficiary’s last name.
4. Beneficiary 1 23-23 Text First letter of the beneficiary’s
First Initial first name.
5. Beneficiary 8 24-31 Numeric Date Date of birth of the Beneficiary.
Date of Birth (CCYYMMDD format).
6. Beneficiary Sex 1 32-32 Alpha- Beneficiary Gender Code
Code numeric
7. Interested Party 15 33-47 Text Most recent Document Control
DCN Number successfully submitted
by the interested party RRE on its
MSP Input File.
Use this field to assist in
matching the Unsolicited MSP
Response Detail Record to your
previously submitted coverage
records.
8. Filler 2 48-49 Alpha- Not Used. Filled with spaces.
numeric
9. Last 1 50-50 Alpha- Last action performed on the
Transaction numeric MSP occurrence by the BCRC
Type based on information from the
entity identified in the Modifier
Type Code and Modifier Name
(Fields 33 and 34).
Values:
‘0’ = Update
‘1’ = Delete
10. Entitlement 1 51-51 Alpha- Reason for beneficiary’s
Reason numeric Medicare Entitlement:
Values:
‘A’ = Aged
‘B’ = ESRD
‘G’ = Disabled

H-2
GHP User Guide Appendix H: Unsolicited MSP Response File Specifications

Field Name Size Displacement Data Type Description

11. Coverage Type 1 52-52 Alpha- Type of insurance coverage
numeric reflected on the MSP occurrence.
Values:
‘J’ = Hospital Only
‘K’ = Medical Only
‘A’ = Hospital and Medical
‘R’ = Health Reimbursement
Arrangement (HRA)
12. Insurer’s Name 32 53-84 Text Name of the most current
insurer/TPA Medicare has
associated with the MSP
occurrence.
13. Insurer’s 32 85-116 Text Address Line 1 for the most
Address 1 current insurer/TPA Medicare has
associated with the MSP
occurrence.
14. Insurer’s 32 117-148 Text Address Line 2 for the most
Address 2 current insurer/TPA Medicare has
associated with the MSP
occurrence.
15. Insurer’s City 15 149-163 Text City for the most current
insurer/TPA Medicare has
associated with the MSP
occurrence.
16. Insurer’s State 2 164-165 Alpha State for the most current
insurer/TPA Medicare has
associated with the MSP
occurrence.
17. Insurer’s Zip 9 166-174 Alpha- Zip Code for the most current
Code numeric insurer/TPA Medicare has
associated with the MSP
occurrence.
18. Filler 9 175-183 Alpha- Not Used.
numeric Filled with spaces.
19. MSP Effective 8 184-191 Numeric Date Effective Date of the MSP
Date occurrence posted on the
Medicare CWF.
20. MSP 8 192-199 Numeric Date End date of the MSP occurrence
Termination posted on the Medicare CWF.
Date * All zeros if open-ended (i.e., if
coverage is not terminated).

H-3
GHP User Guide Appendix H: Unsolicited MSP Response File Specifications

Field Name Size Displacement Data Type Description

21. Relationship 2 200-201 Alpha- Covered Individual’s
Code numeric Relationship to Active Employee:
Values:
‘01’ = Covered Individual is
Active Employee
‘02’ = Spouse or Common Law
Spouse
‘03’ = Child
‘20’ = Domestic Partner
‘04’ = Other Family Member
22. Policy Holder’s 9 202-210 Text Active Employee’s/Subscriber’s
First Name First Name Medicare has
associated with the MSP
occurrence.
23. Policy Holder’s 16 211-226 Text Active Employee’s/Subscriber’s
Last Name Last Name Medicare has
associated with the MSP
occurrence.
24. Policy Holder’s 12 227-238 Alpha- Subscriber/Employee SSN
SSN numeric Medicare has associated with the
MSP occurrence.
May contain all spaces if none
was supplied by an RRE or other
entity.
25. Employer’s 32 239-270 Text Name of the most current
Name employer or other plan sponsor
Medicare has associated with the
MSP occurrence.
26. Employer’s 32 271-302 Text Address Line 1 of the most
Address 1 current employer or other plan
sponsor Medicare has associated
with the MSP occurrence.
27. Employer’s 32 303-334 Text Address Line 2 of the most
Address 2 current employer or other plan
sponsor Medicare has associated
with the MSP occurrence.
28. Employer’s 15 335-349 Text City of the most current employer
City or other plan sponsor Medicare
has associated with the MSP
occurrence.
29. Employer’s 2 350-351 Alpha State Code of the most current
State employer or other plan sponsor
Medicare has associated with the
MSP occurrence.
30. Employer’s Zip 9 352-360 Alpha- Zip Code of the most current
Code numeric employer or other plan sponsor
Medicare has associated with the
MSP occurrence.

H-4
GHP User Guide Appendix H: Unsolicited MSP Response File Specifications

Field Name Size Displacement Data Type Description

31. Group Policy 20 361-380 Text Group number Medicare has
Number associated with the MSP
occurrence.
32. Individual 17 381-397 Text Individual policy number
Policy Number Medicare has associated with the
MSP occurrence.
33. Modifier Type 3 398-400 Alpha- Code identifying the type of
Code numeric entity that last changed the MSP
occurrence.

34. Modifier Name 32 401-432 Text Modifier Name/Description of the

last entity that changed the MSP
occurrence.
35. Change Reason 2 433-434 Alpha- Code identifying the reason for
Code numeric the last change to the MSP
occurrence (if known).
36. Last Update 8 435-442 Numeric Date Date the BCRC last changed the
Applied Date MSP occurrence.
(CCYYMMDD format).
37. Filler 51 443-493 Alpha- Not used.
numeric Filled with spaces.
38. Current 8 494-501 Numeric Date Effective Date of Medicare Part
Medicare Part A Coverage.
A Entitlement (CCYYMMDD format).
Date
39. Current 8 502-509 Numeric Date Termination Date of Medicare
Medicare Part Part A Coverage
A Termination (CCYYMMDD format).
Date
* All zeros if open-ended (i.e., if
coverage is not terminated).
40. Current 8 510-517 Numeric Date Effective Date of Medicare Part B
Medicare Part Coverage.
B Entitlement (CCYYMMDD format).
Date
41. Current 8 518-525 Numeric Date Termination Date of Medicare
Medicare Part Part B Coverage
B Termination (CCYYMMDD format).
Date
* All zeros if open-ended (i.e., if
coverage is not terminated).
42. Current 5 526-530 Alpha- Contractor Number of the current
Medicare Part numeric Medicare Part C Plan in which
C Plan Number the beneficiary is enrolled.
43. Current 8 531-538 Numeric Date Effective Date of coverage
Medicare Part provided by current Medicare
C Entitlement Part C Plan.
Date (CCYYMMDD format).

H-5
GHP User Guide Appendix H: Unsolicited MSP Response File Specifications

Field Name Size Displacement Data Type Description

44. Current 8 539-546 Numeric Date Termination Date of coverage
Medicare Part provided by current Medicare
C Termination Part C Plan.
Date (CCYYMMDD format).
* All zeros if open-ended (i.e., if
coverage is not terminated).
45 Filler 54 547-600 Alpha- Not Used.
numeric Filled with spaces.

Unsolicited MSP Response File Trailer Record

Table H-3: Section 111 GHP Unsolicited MSP Response File Trailer Record - 600 bytes
Field Name Size Displacement Data Type Description
1. Trailer Type 4 1-4 Alpha-numeric Contains a value of ‘USOT'.
Code
2. RRE ID 9 5-13 Numeric Section 111 RRE ID.
3. File Type 4 14-17 Alpha-numeric Contains a value of ‘USOL'.
4. File Date 8 18-25 Numeric Date Date file created by the BCRC
(CCYYMMDD format).
5. File Record 9 26-34 Numeric Number of response detail records
Count contained in this file. Does not include
the header and trailer records in the
count.
Will contain a value of all zeros if
there were no Unsolicited MSP
Response records to transmit to the
RRE for the month.
6. Filler 566 35-600 Alpha-numeric Not Used.
Filled with spaces.

H-6
GHP User Guide Appendix I: Alerts

Appendix I Alerts
Recent Alerts related to GHP Section 111 reporting are posted on, and may be downloaded from,
the Section 111 web site: https://go.cms.gov/mirghp. To view older Alerts, click on the Archive
link on the left-hand side of the page or https://go.cms.gov/MIRGHPArchive.

I-1
GHP User Guide Appendix J: Acronyms

Appendix J Acronyms
The following table contains a list of acronyms related to Section 111. It includes abbreviations
related to both GHP and Non-GHP (Liability Insurance (including Self-Insurance), No-Fault
Insurance, and Workers’ Compensation) reporting.

Table J-1: Acronyms

Acronym Description
ANSI American National Standards Institute
ASCII American Standard Code for Information Interchange
BCRC Benefits Coordination & Recovery Center
CMS Centers for Medicare and Medicaid Services
COB Coordination of Benefits Program
COBA Coordination of Benefits Agreement
COBRA Consolidated Omnibus Budget Reconciliation Act of 1985
COBSW COB Secure Website
CRC Commercial Repayment Center
CWF Common Working File
DBA Doing Business As…
DCN Document Control Number
DES Data Encryption Standard
DOB Date of Birth
DOI Date of Incident
E02 COBA Drug Coverage Eligibility
EBCDIC Extended Binary Coded Decimal Interchange Code
EDI Rep Electronic Data Interchange Representative
EGHP Employer Group Health Plan
EIN (FEIN) Employer Identification Number (Federal EIN)
ESRD End Stage Renal Disease
FSA Flexible Spending Account
GHP Group Health Plan
HEW HIPAA Eligibility Wrapper Software
HHS Health and Human Services
HIPAA Health Insurance Portability and Accountability Act of 1996
HICN Health Insurance Claim Number
HRA Health Reimbursement Arrangement
HSA Health Savings Account
HTTPS Hypertext Transfer Protocol over Secure Socket Layer

J-1
GHP User Guide Appendix J: Acronyms

Acronym Description
ICD – 9 – CM International Classification of Diseases, Ninth Revision, Clinical
Modification
ICD – 10 – CM International Classification of Diseases, Tenth Revision, Clinical
Modification
IACS UID Individuals Authorized Access to CMS Computer Services User
Identification Number
ICHRA Individual Coverage Health Reimbursement Arrangement
LGHPs Large Group Health Plans
MBD Medicare Beneficiary Database
MBI Medicare Beneficiary Identifier
MMSEA Medicare, Medicaid and SCHIP Extension Act of 2007
MSP Medicare Secondary Payer
NAIC National Association of Insurance Commissioners Code
NDM Network Data Mover (now known as Connect:Direct)
NCPDP National Council of Prescription Drug Programs
NGHP Non Group Health Plan or Liability Insurance (including Self Insurance),
No-Fault Insurance and Workers’ Compensation
Non – MSP Non Medicare Secondary Payer
ORM Ongoing Responsibility for Medicals
PIN Personal Identification Number
PRA Paperwork Reduction Act
RDS Retiree Drug Subsidy
RRE ID Responsible Reporting Entity Identification Number or Section 111
Reporter ID
RREs Responsible Reporting Entities
Rx BIN Prescription Benefit Identification Number
Rx PCN Prescription Processor Control Number
SCHIP State Children’s Health Insurance Program
SEE Small Employer Exception
SEP Special Enrollment Period
SFTP Secure File Transfer Protocol
SNA Systems Network Architecture
SSH Secure Shell
SSN Social Security Number
SUPPORT Act Substance Use-Disorder Prevention that Promotes Opioid Recovery and
Treatment for Patients and Communities Act
TCP/IP Transmission Control Protocol/Internet Protocol (Internet Protocol Suite)
TIN Tax Identification Number

J-2
GHP User Guide Appendix J: Acronyms

Acronym Description
TPA Third Party Administrator
TPOC Total Payment Obligation to Claimant
TrOOP True Out of Pocket
TrOOP Rx BIN/Rx PCN TrOOP specific drug payment code
URL Uniform Resource Locator (Website address)
VAN Value Added Network
VDEA Voluntary Data Exchange Agreement
VDSA Voluntary Data Sharing Agreement
VTAM Virtual Telecommunications Access Method

J-3
GHP User Guide Appendix K: Previous Version Changes

Appendix K Previous Version Changes

Version 5.8
Patient relationship code “20” (Domestic Partner) has been removed as a valid code from the
Working Aged list in the SP52 error code description.
The notes associated with the Current Medicare Part D Plan Contractor Number, Current Part D
Plan Enrollment Date, and Current Medicare Part D Plan Termination Date fields (Nos. 57, 58,
and 59) have been edited for clarity.
Version 5.7
To prevent a supplemental drug record from being created with a missing or invalid insurer name
when a Retiree Drug Subsidy (RDS) record is submitted, a valid insurer name is now required
when the Action Type is “S” (i.e., Subsidy reporting record) (see Non-MSP Response File Detail
Record, Field 27). Concurrently, validation logic for error code SP25 (invalid or no insurer
name) has been updated (see Section 111 GHP SP Error Codes).
To clarify input file processing requirements for Medicare Secondary Payer (MSP) occurrences,
clarification has been provided in instances where beneficiaries expand or reduce their insurance
coverage (Section 7.2.6.1).
For Section 111 RREs submitting drug records, additional instructions have been provided for
those who receive RX 07 error codes when submitting drug records for beneficiaries who have
not yet enrolled in a Medicare Prescription Drug Plan (Part D) (Section 7.2.8.3).
Disposition code 51 is sent back on query response files often because an individual was not
found to be (could not be matched with) a Medicare beneficiary. To clarify, when individuals
cannot be found, it is because they do not have Medicare Part A entitlement. Individuals may be
Medicare beneficiaries but have Medicare Part B coverage only. For these individuals, the MSP
provision does not apply.) (See Section 111 GHP Disposition Codes).
Version 5.6
To clarify Medicare Secondary Payer (MSP) input file requirements, information regarding
Individual Coverage Health Reimbursement Arrangements (ICHRAs) has been added. All
HRAs, including ICHRAs, Qualified Small Employer Health Reimbursement Arrangements
(QSEHRAs), and excepted benefit HRAs, are subject to the applicable MSP provisions
regardless of whether or not they have an end-of-year carry-over or roll-over feature
(Section 7.2.7).
Version 5.5
The Substance Use-Disorder Prevention that Promotes Opioid Recovery and Treatment
(SUPPORT) for Patients and Communities Act, Title IV Section 4002, will require Group Health
Plan (GHP) Responsible Reporting Entities (RREs) to report primary prescription drug coverage
through the Section 111 process for calendar quarters beginning on or after January 1, 2020.
Additionally, as of July 2019, GHP RREs who report primary prescription drug coverage using
the Basic reporting option will now receive Medicare Part D enrollment information on their
response files. (Section 6.2).
The retention period for downloading response files has been updated from 180 days to 60 days
(Section 8.1.2 and 8.1.3).

K-1
GHP User Guide Appendix K: Previous Version Changes

The system has been updated to accept the valid patient relationship disposition codes of 05
(Step Child) and 18 (Parent) as valid entries (see Section 111 GHP SP Error Codes).
RREs can download the latest PC/server version of the HIPAA Eligibility Wrapper (HEW)
software from the Section 111 MRA application, which is compatible with Windows 10 (Section
7.3.4 and Appendix B).
Because file uploads have been restricted to certain types, RREs using the HTTPS file
transmission method can only upload files with the file extension of .txt. Any other file type will
generate an Invalid File error message (Sections 7.5.1 and8.1.3).
Version 5.4
Date formats for Severe Error header and trailer records have been corrected (Table 7-5 and
Table 7-11).
Version 5.3
The contact protocol for the Section 111 data exchange escalation process has been updated
(Section 12.2).
To help prevent input errors on the Section 111 Insurer Name field (27), additional value checks
have been added to the SP25 error code (Table D-2).
Version 5.2
To meet Section 111 requirements, a Paperwork Reduction Act (PRA) disclosure statement has
been added to the front of this guide.
Starting Oct. 1, 2018, GHP RREs will be required to include the Insurer Name when submitting
supplemental drug (“D”) records on Non-MSP input files. As a result, a new SP25 error code has
been added (Appendix Tables C-2 and D-2).
Note: Because we do attempt to convert “S” records into “D” records (Section 7.4.9: Converting
an “S” Record to a “D” Record), this error may also occur if the “S” records are missing, or do
not include, the Insurer Name during conversion.
Version 5.1
For input layout files, the format of the Medicare ID Medicare Beneficiary Identifier (MBI) has
been clarified in fields and examples.
If you provide a Medicare ID (HICN or MBI), or an SSN, on input files, the system will return
the most current Medicare ID in the response files.
Version 5.0
As required by Section 501 of the Medicare Access and CHIP (Children’s Health Insurance
Program) Reauthorization Act (MACRA) of 2015, CMS must discontinue all Social Security
Number (SSN)-based Medicare identifiers and distribute a new 11-byte Medicare Beneficiary
Identifier (MBI)-based card to each Medicare beneficiary by April 2019. CMS has exempted all
Medicare Secondary Payer (MSP) processes from exclusive use of the MBI. Therefore, Group
Health Plan (GHP) RREs are permitted to continue to report for Section 111 mandatory insurer
reporting using: full SSN, Health Insurance Claim Number (HICN), or MBI. All fields formerly
labeled as “HICN” have been relabeled as “Medicare ID” and can accept either a HICN or the
new MBI.
Additional Notes:

K-2
GHP User Guide Appendix K: Previous Version Changes

Medicare Identifier on Section 111 Response Files

The most current Medicare ID (HICN or MBI) will be returned in the Section 111 response files
in the “Medicare ID” field. Consequently, if an RRE submits information with a HICN and the
Medicare beneficiary has received their MBI, the MBI will be returned. Otherwise, the most
current HICN will be returned. RREs may submit subsequent Section 111 information for this
Medicare beneficiary using either the HICN or MBI.
Medicare Identifier on Outgoing Correspondence
As part of the New Medicare Card Project changes, Benefits Coordination and Recovery Center
(BCRC) and Commercial Repayment Center (CRC) issued correspondence will use the
Medicare identifier that RREs most recently provided when creating or updating a Medicare
Secondary Payer (MSP) record. Consequently, if the most recent information that was received
used a HICN, all subsequent issued correspondence will be generated with the HICN as the
Medicare ID. If the most recent information received used an MBI, all subsequent issued
correspondence will be generated with the MBI as the Medicare ID.
Direct Data Entry (DDE) Users: Claim Searches
Section 111 DDE users will be able to search for saved and submitted claims using the HICN or
MBI.
When searching for claims via the Claim Listing page, either the MBI or the HICN can be
entered in the Medicare ID field. All claims that match for the Medicare beneficiary will display
in the search results, regardless of Medicare identifier that was used to establish the claim.
Retiree Drug Subsidy (RDS) Unsolicited Response Files
RDS Unsolicited Response Files will contain the HICN or MBI in the “Medicare ID” field, as
sent by the RDS system.
General
RREs will still be able to use an SSN to query via the Health Eligibility Wrapper (HEW)
270/271 query process. The most current Medicare identifier, either HICN or MBI will be
returned in the “Medicare ID” field.
Other Changes
The contact protocol for the Section 111 data exchange escalation process has been updated (see
Section 12.2).
Version 4.9
To prevent calls to the help center to increase transaction limits, the limit for COBSW Section
111 beneficiary lookups has been increased from 100 to 500 transactions per calendar month.
See Section 9.1.2.
Version 4.8
Information about the CMS Section 111 Resource Mailbox has been updated to clarify usage
details. See Chapter 2 and Chapter 12.
Version 4.7
The Coordination of Benefits Secure Website (COBSW) Section 111 URL has changed to
https://www.cob.cms.hhs.gov/Section111/. See changes made throughout this user guide.

K-3
GHP User Guide Appendix K: Previous Version Changes

Version 4.6
Updated the description for Field 19 (MSP Effective Date) to clarify how an MSP Effective Date
may be automatically set to a future date (See Table A-8).
Updated the description for error code SP31 to clarify the parameters for the error code being
returned: The SP31 error may also be returned if the record was submitted prior to the
individual’s Medicare entitlement effective date. The RRE should continue to resend the record
until it is accepted, the individual is no longer an Active Covered Individual, or GHP coverage is
terminated. (See Table D-2).
Version 4.5
Updated hyperlink to the 270/271 Health Care Eligibility Benefit Inquiry and Response
Companion Guide for Mandatory Reporting Group Health Plan Entities in Section 7.3.
The Department of Health & Human Services has adopted a policy treating same-sex marriages
on the same terms as opposite-sex marriages to the greatest extent reasonably possible. Any
same-sex marriage legally entered into in a U.S. jurisdiction that recognizes the marriage -
including one of the 50 states, the District of Columbia, or a U.S. territory -- or a foreign country,
so long as that marriage would also be recognized by a U.S. jurisdiction, will be recognized.
Consistent with this policy and the purpose of the MSP provisions, effective January 1, 2015, the
rules below apply with respect to the term “spouse” under the MSP Working Aged provisions.
This is true for both opposite-sex and same-sex marriages as described herein.
• If an individual is entitled to Medicare as a spouse based upon the Social Security
Administration’s rules, that individual is a “spouse” for purposes of the MSP Working
Aged provisions.
• If a marriage is valid in the jurisdiction in which it was performed as described herein,
both parties to the marriage are “spouses” for purposes of the MSP Working Aged
provisions.
• Where an employer, insurer, third party administrator, GHP, or other plan sponsor has a
broader or more inclusive definition of spouse for purposes of its GHP arrangement, it
may (but is not required to) assume primary payment responsibility for the “spouse” in
question. If such an individual is reported as a “spouse” pursuant to MMSEA Section
111, Medicare will pay accordingly and pursue recovery, as applicable.
Version 4.4
To make it clear that the most recent TIN Reference File name and address information is used
for recovery purposes the “Changing TINs or TIN Addresses” paragraph in Section 7.2.2 was
updated.
Version 4.3
Branding updates for the Benefits Coordination & Recovery Center (BCRC).
Version 4.2
Updated USPS links in Sections 7.2.2.2 and 7.2.6.3.
Version 4.1
References to the Medicare Secondary Payer Recovery Contractor (MSPRC) have been replaced
with references to the Commercial Repayment Center (CRC).

K-4
GHP User Guide Appendix K: Previous Version Changes

• CMS has transitioned all the functions and workloads related to GHP MSP recovery, with
the exception of provider, physician, or other supplier recovery, to the CRC. The CRC is
responsible for identifying and recovering Medicare mistaken payments where a GHP
has primary payment responsibility. Some of these responsibilities include: issuing
recovery demand letters when mistaken primary payments are identified, receiving
payments, resolving outstanding debts, and referring delinquent debt to the Department
of Treasury for further collection actions, including the Treasury Offset Program, as
appropriate.
Clarification on how to accurately report a Coverage Termination Date (Field 11) on the MSP
Input File has been provided.
As a result of the re-design of the Medicare and Coordination of Benefits pages on the CMS.gov
Website, all outdated hyperlinks have been replaced in this document.
Users no longer need to register for computer-based training (CBT). CBTs can be accessed
directly from the CMS website. Please see Chapter 13.

K-5