Download:
pdf |
pdfMMSEA Section 111
MSP Mandatory Reporting
GHP USER GUIDE
Version 2.0
December 17, 2008
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 OMB control number. The valid OMB control number for this information
collection is 0938-1024 (Expires 04/30/2021). The time required to complete this information collection is
estimated to average 22 hours 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.
MMSEA Section 111 GHP User Guide
Revision History
Date
August 1, 2008
August 11, 2008
September 9, 2008
October 3, 2008
Version
1.0
1.1
1.2
1.3
October 9, 2008
October 14, 2008
December 17, 2008
1.4
1.5
2.0
Reason for Change
Initial Version
Various Changes - Unpublished
Various Changes - Unpublished
Incorporation of changes related to published
website articles.
Final clearance edits.
Initial Publication – Final Version
Second Publication
2
MMSEA Section 111 GHP User Guide
Table of Contents
1
SUMMARY OF VERSION 2.0 UPDATES ......................................................6
2
INTRODUCTION ............................................................................................8
3
MMSEA SECTION 111 OVERVIEW ..............................................................9
4
MEDICARE ENTITLEMENT, ELIGIBILITY AND ENROLLMENT................10
5
MSP OVERVIEW FOR GHP.........................................................................12
6
THE GHP PROCESS ...................................................................................15
6.1
Overview ........................................................................................................................................ 15
6.2
GHP Reporting Options ............................................................................................................. 16
6.2.1
Basic Reporting Option...................................................................................................... 16
6.2.2
Expanded Reporting Option ............................................................................................. 17
7
GHP MANDATORY REPORTING REQUIREMENTS..................................19
7.1
General Reporting Requirements............................................................................................ 19
7.1.1
Responsible Reporting Entities ....................................................................................... 19
7.1.1.1
Who Must Report ......................................................................................................... 19
7.1.1.2
Use of Agents ............................................................................................................... 19
7.1.2
Active Covered Individuals ............................................................................................... 19
7.1.2.1
Finder File as an Alternative to the Age Threshold ............................................ 21
7.1.3
Inactive Covered Individuals ............................................................................................ 21
7.1.4
File Format............................................................................................................................. 22
7.1.5
Data Formatting Standards ............................................................................................... 22
7.1.6
Section 111 Registration.................................................................................................... 24
7.1.6.1
Purpose of the Registration Process ..................................................................... 24
7.1.6.2
Registration Timeframes ........................................................................................... 24
7.1.6.3
Overview of the Registration Process.................................................................... 25
7.1.7
Differences Between VDSA/VDEA and Section 111 Files ......................................... 27
7.1.8
File Submission Timeframes ............................................................................................ 28
7.2
MSP Input File Requirements ................................................................................................... 30
7.2.1
Overview ................................................................................................................................ 30
7.2.2
TIN Reference File ............................................................................................................... 31
7.2.2.1
Special GHP Extension For Reporting Employer TINs ...................................... 32
7.2.2.2
TIN Validation................................................................................................................ 33
7.2.3
Record Matching Criteria................................................................................................... 34
7.2.3.1
Individuals ..................................................................................................................... 34
7.2.3.2
MSP Occurrences ........................................................................................................ 34
7.2.4
Small Employer Exception (SEE) .................................................................................... 35
7.2.5
Initial MSP Input File Submission.................................................................................... 37
3
7.2.6
Quarterly Update MSP Input File Submissions............................................................ 37
7.2.6.1
Add, Delete, Update Transactions........................................................................... 38
7.2.7
MSP Input File Detailed Requirements........................................................................... 41
7.2.8
Special GHP Reporting Extension For Dependents ................................................... 43
7.2.9
Processing Response Files .............................................................................................. 45
7.2.9.1
Disposition Codes ....................................................................................................... 45
7.2.9.2
SP Error Codes............................................................................................................. 46
7.2.9.3
Rx Disposition and Rx Error Codes........................................................................ 48
7.2.9.4
Expanded Option Only - Part D Eligibility and Enrollment Data...................... 50
7.2.9.5
File Level and Threshold Errors .............................................................................. 50
7.2.9.6
Late Submission and Compliance Flags ............................................................... 51
7.2.9.7
Split Entitlement Indicator – Multiple Response Records ................................ 52
7.2.9.8
End Stage Renal Disease (ESRD)............................................................................ 52
7.3
Query Only Input File Requirements ...................................................................................... 54
7.3.1
Overview ................................................................................................................................ 54
7.3.2
Query Only Input File Detailed Requirements.............................................................. 54
7.4
Non-MSP Input File Requirements .......................................................................................... 55
7.4.1
Overview ................................................................................................................................ 55
7.4.2
Action Types ......................................................................................................................... 56
7.4.2.1
N – Query Records ...................................................................................................... 56
7.4.2.2
D – Supplemental Prescription Drug Coverage Records .................................. 56
7.4.2.3
S – RDS Retiree File Records ................................................................................... 57
7.4.3
Record Matching Criteria................................................................................................... 57
7.4.3.1
Individuals ..................................................................................................................... 57
7.4.3.2
Supplemental Prescription Drug Records ............................................................ 57
7.4.4
Initial Non-MSP Input File Submission........................................................................... 58
7.4.5
Update Non-MSP Input File Submissions ..................................................................... 59
7.4.5.1
Add, Delete, Update Transactions........................................................................... 60
7.4.6
Detailed Non-MSP Input File Requirements ................................................................. 61
7.4.7
Processing Response Files .............................................................................................. 62
7.4.7.1
Part D Eligibility and Enrollment Data.................................................................... 62
7.4.7.2
Processing “D” Response Records........................................................................ 63
7.4.7.3
Processing “N” Response Records........................................................................ 64
7.4.7.4
Processing “S” Response Records........................................................................ 65
7.4.7.5
Non-MSP Input File Level and Threshold Errors ................................................. 65
7.4.7.6
End Stage Renal Disease (ESRD)............................................................................ 65
7.4.8
True-Out-of-Pocket (TrOOP) Facilitation RxBIN and PCN Codes ........................... 66
7.4.9
RDS Retiree File Submission ........................................................................................... 66
7.5
Testing the Section 111 Reporting Process ......................................................................... 70
7.6
Summary of Steps to Register, Test and Submit Production Files ................................ 72
8
ELECTRONIC DATA EXCHANGE ..............................................................73
8.1
File Transmission Methods....................................................................................................... 73
8.1.1
Connect:Direct (NDM via the AT&T Global Network System (AGNS))................... 73
8.1.2
Secure File Transfer Protocol (SFTP)............................................................................. 74
8.1.3
Hypertext Transfer Protocol over Secure Socket Layer (HTTPS) ........................... 75
9
QUERYING FOR MEDICARE COVERAGE INFORMATION.......................76
4
9.1
How to Obtain Medicare Coverage Information................................................................... 76
9.1.1
File Transmission ................................................................................................................ 76
9.1.2
Beneficiary Automated Status and Inquiry System (BASIS).................................... 77
10
DATA USE AGREEMENT.........................................................................78
11
COB SECURE WEB SITE.........................................................................79
12
CUSTOMER SERVICE AND REPORTING ASSISTANCE.......................79
12.1
EDI Representative.................................................................................................................. 79
12.2
Customer Service Center....................................................................................................... 79
12.3
Contact Protocol for the Section 111 Data Exchange.................................................... 80
13
TRAINING AND EDUCATION...................................................................80
APPENDIX A – MSP FILE SPECIFICATIONS...................................................81
APPENDIX B – QUERY ONLY HEW INPUT/OUTPUT FILE SPECIFICATIONS
..........................................................................................................................108
APPENDIX C – NON-MSP FILE SPECIFICATIONS .......................................111
APPENDIX D – DISPOSITION, ERROR AND COMPLIANCE CODES...........131
APPENDIX E – MMSEA SECTION 111 BASIS REQUEST ATTACHMENT ...146
APPENDIX F – MMSEA SECTION 111 HTTPS/SFTP INCOMING FILE
NAMING CONVENTIONS ................................................................................148
APPENDIX G – MMSEA SECTION 111 STATUTORY LANGUAGE ..............154
APPENDIX H – MMSEA SECTION 111 DEFINITIONS AND REPORTING
RESPONSIBILITIES.........................................................................................157
5
MMSEA Section 111 GHP User Guide
1
Summary of Version 2.0 Updates
The following updates have been made in Version 2.0 of the MMSEA Section 111 GHP
User Guide:
• The explanation of Active Covered Individuals in Section 7.1.2 has been updated
to exclude individuals covered by COBRA with one exception to this rule noted
for individuals with ESRD.
• The age threshold used in the definition of Active Covered Individuals has been
temporarily raised to 55 from 45 years old. The age threshold will be lowered
back to 45 on January 1, 2011. The explanation of Active Covered Individuals in
Section 7.1.2 has been updated for this change. Notations on this age threshold
change have also been made in Sections 7.1.7, 7.2.1 and 7.2.9.1.
• Section 7.1.2.1 has been added to describe a “finder file” option as an alternative
to using the age threshold requirement in the definition of an Active Covered
Individual.
• Section 7.1.7 was updated to note the new compliance flags and add a special
note about initial MSP Input File submissions for former VDSA/VDEA partners.
• Further clarification was added to Section 7.2.2 regarding the TIN Reference File.
In particular, it has been noted that once the full TIN Reference File has been
submitted, only new or changes records need to be sent on subsequent
submissions rather than a full replacement file. Also, the file is to contain only
one record per TIN/TIN Indicator combination.
• Section 7.2.2.1 “Special GHP Extension For Reporting Employer TINs” has been
added to explain the temporary use of “pseudo-TINs” until January 1, 2010 when
employer TINs are unavailable.
• Section 7.2.2.2 “TIN Validation” has been added to explain how employer and
insurer TINs are validated on MSP Input and TIN Reference Files.
• A new paragraph was added to Section 7.2.6.1, “Changing Information Used to
Determine Medicare Secondary Payer” to further clarify the use of update
transactions. A similar explanation was added to Section 7.4.5.1 pertaining to the
Non-MSP Input File process.
• Clarification was added regarding the Document Control Number (DCN) in
Section 7.2.7. This number needs only be unique within the current file being
submitted.
• Information was added on determining employer size to Section 7.2.7 and the
description of Field 16 on the MSP Input File in Appendix A.
• Section 7.2.7 has been updated to explain reporting requirements regarding
Flexible Savings Accounts (FSAs), Health Savings Accounts (HSAs), Health
Reimbursement Accounts (HRAs), and stand-alone dental and vision care
coverage.
• Section 7.2.8 has been changed to lengthen the extension for RREs to collect
the SSNs for dependents whose initial GHP effective date is prior to January 1,
2009. RREs now have until January 1, 2011 (instead of 2010) to report on these
specific individuals.
6
•
•
•
•
•
•
•
•
•
•
•
•
A set of compliance flags have been added to the end of the MSP Response File
record layout. A description of these fields is provided in Section 7.2.9.6.
Compliance Code values used for these flags can be found in Appendix D.
The reference to File Transfer Protocol (FTP) over the AT&T Global Network
Services (AGNS) was removed from the description of the Connect:Direct file
transmission method in Section 8.1.1. Note that Secure FTP (SFTP) is still an
available option over the Internet. FTP over AGNS is not. Connect:Direct (NDM)
must be used for the AGNS.
The dataset naming conventions to be used for Connect:Direct were corrected in
Section 8.1.1.
Sections 8.1.2 and 8.1.3 were updated to note that the links to documentation
related to SFTP and HTTPS listed there are only to be used for those
transmitting via these methods prior to April 2009. These file transmission
methods will be transitioned to the COB Secure Website at that time.
Clarification was added in Section 9.1.2 to indicate that the limit on queries that
can be submitted through BASIS is 200 per Section 111 Reporter ID per month.
Section 12.3 “Contact Protocol for the Section 111 Data Exchange” has been
added to explain how to elevate Section 111 data exchange issues at the COBC.
The description of Field 8 Coverage Type on the MSP Input File in Appendix A
has been updated with an explanation for Health Reimbursement Accounts.
Clarification has been added to data element descriptions for the MSP Input File
in Appendix A related to reporting by Third Party Administrators (TPAs), SelfInsured entities, and reporting on Taft-Hartley multi-employer plans.
Updates have been made to the descriptions of SP Error Codes in Appendix D to
further clarify their meaning and corrective actions. Some SP Error Codes
originally marked as “RRE Responsible” have been changed to “COBC
Responsible”.
The description for disposition code ‘51’ was updated in Appendix D to include
situations where neither a HICN nor SSN was submitted for the individual on an
input record.
The description of the ‘BY’ Disposition Code was updated in Appendix D.
All header and trailer indicator fields have been changed to alphanumeric data
types from alphabetic.
7
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 is for use by all Section 111 GHP responsible reporting entities.
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.
Section 111 responsible reporting entities (RREs) will be notified when new versions are
available. Please check the CMS Section 111 Web page often at
www.cms.hhs.gov/MandatoryInsRep for the latest version of the guide and for other
important information.
8
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 are 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 Appendices G and H.
9
4
Medicare Entitlement, Eligibility and Enrollment
This section provides a general overview of Medicare entitlement, eligibility and
enrollment. Please refer to www.cms.hhs.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.
Prescription Drug Coverage (Part D) - 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). Depending on
your reporting option selected, CMS may also share Part D eligibility and enrollment
information as well. In your response files you will get information about beneficiary
eligibility and enrollment.
10
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 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.
11
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.
Some people who have Medicare also have group health coverage. Often, employerprovided 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.
12
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.
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,
•
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.
or
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 MSP exception: 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 an
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 individual.
See the Small Employer Exception section of this guide for more information.
People with Permanent Kidney Failure
Medicare is 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 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
13
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 to recover the mistaken Medicare payment. CMS has a Medicare
Secondary Payer Recovery Contractor (MSPRC) which is responsible for recovery
actions. The MSPRC 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 MSPRC 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 Coordination of Benefits Contractor
The purposes of the Coordination of Benefits (COB) program are to identify the health
benefits available to a Medicare beneficiary and to coordinate payment process to
prevent mistaken payment of Medicare benefits. The CMS Coordination of Benefits
Contractor (COBC) consolidates the activities that support the collection, management,
and reporting of other insurance coverage for Medicare beneficiaries. The COBC does
not process claims, nor does it handle any mistaken payment recoveries or claims
specific inquiries. Instead, the COBC updates the Medicare systems and databases
used in the claims payment and recovery processes. The COBC 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.
14
6
6.1
The GHP Process
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 will take place
between the RREs and the CMS Coordination of Benefits Contractor (the COBC). The
COBC will be managing 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 COBC. In exchange,
the COBC 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.
The Section 111 GHP reporting process includes an option to exchange prescription
drug coverage information to coordinate benefits related to Medicare Part D. CMS is
also allowing 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
using the Section 111 GHP reporting process.
Section 111 RREs are required to register with the COBC 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. 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 six
different record layouts. A responsible reporting entity (RRE) electronically transmits a
data file to the COBC. The COBC 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 COBC 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 COBC 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.
15
In only one instance – as part of the RDS file exchange process – will the COBC
transmit a response file to an RRE without having first processed a specific input file. In
ordinary circumstances it will always be an input file that will generate a response file.
6.2
GHP Reporting Options
Pursuant to Section 111, the Secretary has determined that GHP RREs are to provide
CMS with information regarding hospital and medical GHP coverage they make
available to Medicare beneficiaries. 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. However, CMS is very
interested in coordinating benefits related to GHP prescription drug benefits and
Medicare Part D (prescription drug) coverage for these same Medicare beneficiaries. As
a result we have made 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 Expanded Reporting Option includes the
minimum requirements for Section 111 plus the exchange of prescription drug coverage
information. If you select the Basic Reporting Option, CMS will return just Medicare Part
A entitlement and Parts B and C enrollment information on your response files. RREs
participating through the Expanded Reporting Option will also receive Medicare Part D
eligibility and enrollment information. Most current users of the VDSA and VDEA
program are already participating at the Section 111 Expanded Reporting Option level,
and CMS encourages all RREs that are existing VDSA and VDEA partners to use the
Section 111 Expanded Reporting Option.
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. The COBC will only return entitlement/enrollment information for
Medicare Parts A, B and C with this option.
For GHP insurers that choose the Basic Reporting Option, CMS will be happy to accept
reporting of prescription drug coverage that is in addition to your hospital and medical
reporting. If you anticipate reporting such additional drug coverage on more than an
occasional basis we recommend that you choose to report using the Expanded
Reporting Option.
16
MMSEA Section 111 Basic GHP Reporting Option Files
File Type
GHP MSP Input File
GHP MSP Response File
TIN Reference File
Query Only Input File
Query Only Response File
Description
This is the data set transmitted from
a MMSEA Section 111 responsible
reporting entity (RRE) to the COBC
that is used to report information
regarding Active Covered
Individuals.
This is the data set transmitted from
the COBC to the MMSEA Section
111 RRE after the information
supplied in the RRE’s MSP Input
File has been processed.
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.
This is a query file used to obtain
Medicare Part A entitlement and
Parts B and C enrollment
information of potential Medicare
beneficiaries.
After the COBC 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 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 File with supplemental
prescription drug coverage records, 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 file. The COBC 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 prescription drug
coverage information. If you choose the Expanded Reporting Option, you must provide
CMS with information about drug coverage for Medicare beneficiaries on a regular basis
in the form of primary drug coverage on the MSP Input File, or supplemental drug
coverage records or RDS retiree file records on the Non-MSP Input File.
17
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 COBC will track your COBA submissions
accordingly.
MMSEA Section 111 Expanded GHP Reporting Option Files
File Type
GHP MSP Input File
GHP MSP Response File
TIN Reference File
GHP Non-MSP Input File
GHP Non-MSP Response File
Query Only Input File
Query Only Response File
Description
This is the data set transmitted from
a MMSEA Section 111 responsible
reporting entity (RRE) to the COBC
that is used to report information
regarding Active Covered
Individuals.
This is the data set transmitted from
the COBC to the MMSEA Section
111 RRE after the information
supplied in the RRE’s MSP Input
File has been processed.
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.
This is the data set transmitted from
a MMSEA Section 111 RRE to the
COBC that is used to report
information regarding the drug
insurance coverage information of
Inactive (e.g. not employed, retired)
Covered Individuals.
This is the data set transmitted from
the COBC to the MMSEA Section
111 RRE after the information
supplied in the Non-MSP Input File
has been processed.
This is a query file used to obtain
Medicare Part A entitlement and
Parts B and C enrollment
information of potential Medicare
beneficiaries.
After the COBC has processed the
Query Only Input File it will return
the Query Only Response File with
Medicare Parts A, B and C
18
File Type
7
7.1
Description
coverage information for individuals
identified as Medicare beneficiaries.
GHP Mandatory Reporting Requirements
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. You must use the definitions given in Appendix H when
determining whether or not you are a responsible reporting entity under this provision.
7.1.1.2 Use of Agents
See the discussion of “agents” with respect to GHP reporting in Appendix H.
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 COBC 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
A GHP responsible reporting entity’s first file submission must contain information for all
individuals meeting the definition of an Active Covered Individual, as 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.
Subsequent quarterly file submissions are to include only new or changed coverage
information, using add, update, and delete transactions.
For purposes of Section 111 reporting, Active Covered Individuals are:
• Effective January 1, 2009 through December 31, 2010, all individuals covered in
a GHP age 55 through age 64 who have coverage based on their own or a family
19
•
•
•
member’s current employment status. Effective January 1, 2011 and subsequent,
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.
All individuals covered in a GHP who are under age 55 (age 45 effective January
1, 2011), 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 on individuals under age 45, you must submit their Medicare Health
Insurance Claim Number (HICN).
An Active Covered Individual is 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. Medicare may be a
secondary payer for these individuals. On the MSP Input File, CMS is requiring the RRE
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 COBC will determine if
the active covered individual is a Medicare beneficiary and whether Medicare is the
primary or secondary payer. The results of this determination are then provided to the
submitter on the returned MSP Response File.
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.
Note: 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. See, also, the section of
this User Guide discussing the Small Employer Exception.
Note: 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.
Note: The MSP provisions for the disabled apply to all employers in a multiemployer/multiple employer GHP if one or more of the employers has 100 or more full
and/or part-time employees.
Note: The age threshold of 55 described above will be lowered to 45 for all MSP Input
Files submitted January 1, 2011 and subsequent.
20
7.1.2.1
Finder File as an Alternative to the Age Threshold
As an alternative to using the age threshold requirements defined above, CMS is
making a “finder file” option available to Section 111 GHP RREs. This option involves
the RRE first sending a query file through which the COBC would identify any
Medicare beneficiaries and return these positive identifications to the RRE. The RRE
would then submit MSP Input File records for those identified Medicare beneficiaries.
However, use of a “finder file” is not a foolproof method of identifying all Active
Covered Individuals who are Medicare beneficiaries that should be reported. CMS
believes that the use of a finder file is functionally less precise than routine reporting
of all Active Covered Individuals as defined using the age threshold. Consequently,
use of the “finder file” option may increase an RRE’s probability of underreporting all
Active Covered Individuals who are Medicare beneficiaries, putting the RRE in
jeopardy of noncompliance with the Section 111 reporting requirements. This
possibility should be carefully weighed by any RRE considering the “finder file”
reporting option.
If you choose to use the “finder file” option, 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 COBC uses as matching criteria for individuals (SSN, name, date of birth, and
gender). Query files can be submitted no more often than on a monthly basis. 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.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.
21
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 Reporter ID. You will receive your Reporter 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 table below defines the formatting standard defined for each data type found in
the Section 111 files, both input and response.
Data/Field
Type
Numeric
Alpha
Formatting Standard
Zero through 9 (0 to 9)
Padded with leading zeroes
A through Z
Left justified
Non-populated bytes padded
with spaces
Alphabetic characters sent in
lower case will be converted
and returned in upper case.
22
Examples
Numeric (5): “12345”
Numeric (5): “00045”
Alpha (12): “TEST EXAMPLE”
Alpha (12): “EXAMPLE “
Data/Field
Type
Alpha-Numeric
Text
Date
Filler
Internal Use
Formatting Standard
A through Z (all alpha)
0 through 9 (all numeric)
Left justified
Non-populated bytes padded
with spaces
Alphabetic characters sent in
lower case will be converted
and returned in upper case.
A through Z (all alpha) + 0
through 9 (all numeric) +
special characters:
Comma (,)
Ampersand (&)
Space ( )
Dash (-)
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.
Format is field specific
Fill with all zeroes if empty (no
spaces are permitted)
Populate with spaces
Populate with spaces
Examples
Alphanum (8): “AB55823D”
Alphanum (8): “MM221 “
Text (8): “AB55823D”
Text (8):
“XX299Y “
Text (18):
“[email protected]”
Text (12): “ 800-555-1234”
Text (12): “#34
“
CCYYMMDD (e.g.
“19991022”)
Open ended date: “00000000”
The above standards apply unless otherwise noted in layouts.
23
7.1.6 Section 111 Registration
7.1.6.1 Purpose of the Registration Process
The registration process will require responsible reporting entities (RREs) to provide
notification to the COBC of their intent to report data to comply with the requirements
of Section 111 of the MMSEA. Registration by the responsible reporting entity must
be completed before testing between the RRE (or its agent) and the COBC can
begin. Through the registration process, the COBC will obtain the information
needed to:
•
•
•
•
•
•
Validate information provided by the RRE registrant
Assign a Section 111 Reporter ID 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 to each
entity
Establish the necessary file transfer mechanisms, and
Assign a COBC Electronic Data Interchange Representative (EDI Rep) to each
entity to assist with ongoing communication and data exchange.
7.1.6.2 Registration Timeframes
Current VDSA/VDEA Partners
GHP responsible reporting entities that currently have Voluntary Data Sharing
Agreements (VDSAs) or Voluntary Data Exchange Agreements (VDEAs) in place with
CMS and the COBC must complete the following by October 31, 2008:
•
•
MMSEA Section 111 GHP RRE Registration Attachment for VDSA/VDEA
Partners that can be found at
www.cms.hhs.gov/MandatoryInsRep/Downloads/PaperRegistration.pdf
the electronic file transmission information attachment for Connect:Direct
(AGNS) in the same document named above.
Complete instructions are included in the attachment.
All Other GHP Responsible Reporting Entities
GHP RREs that do not currently exchange data with CMS under the VDSA/VDEA
Program will register on the COB Secure Web site (COBSW) from April 1, 2009 through
April 30, 2009 using a new, interactive, Web portal designed for this purpose. Details on
how to complete the Section 111 registration process on the COBSW that starts in April
1, 2009, will be posted on the CMS Section111 Web page at
www.cms.hhs.gov/MandatoryInsRep/. This User Guide will be updated accordingly. You
may review the requirements for registration at
www.cms.hhs.gov/MandatoryInsRep/Downloads/RegistrationOverview.pdf.
24
7.1.6.3 Overview of the Registration Process
Current GHP VDSA/VDEA Partners
Current Insurer GHP VDSA/VDEA partners who are responsible reporting entities will
complete and deliver their registration attachments to the COBC. Note that the COBC
will implement an Internet-based Section 111 application on the COBSW on April 1,
2009. At that time, GHP VDSA/VDEA partners who previously registered for Section 111
by paper will be invited to confirm their registration, set up online accounts and register
individual users for the site. This new application will provide additional options for
submitting files to the COBC and allow users to monitor the status of test and production
file processing for Section 111.
The COBC will process your registration and once it has been accepted, will send you
an e-mail with your Section 111 profile report. This report summarizes the information
you provided on your registration and provides important information you will need for
your data file transmission. It will also contain your Section 111 Reporter ID that you will
need to include on all files transmitted to the COBC. The profile report will also include
your assigned production live date and file submission timeframe for MSP Input Files.
You must sign a copy of your profile report and return it to the COBC in order for your
registration to be complete. At that point you may begin testing your Section 111 files.
All Other Responsible Reporting Entities
All other entities responsible for complying with the Section 111 reporting requirements
will register on the COBSW. An authorized company representative will complete and
submit the registration for the RRE using a new Internet-based application on the
COBSW. When a registration application is submitted, the information provided will be
validated by the COBC. Once this is completed, the RRE will be invited to assign an
Account Manager to return to the COBSW to complete account set up and obtain Login
IDs for individual users associated with that account on the COBSW.
Once account set up has been completed and processed, a profile report will be sent to
the RRE’s authorized representative via e-mail. This report summarizes the information
you provided on your registration and account set up and provides important information
you will need for your data file transmission. It will also contain your Section 111
Reporter ID that you will need to include on all files transmitted to the COBC. The profile
report will include your assigned production live date and file submission timeframe for
MSP Input Files. The RRE’s authorized representative must review, sign and return the
profile report to the COBC. At that point you may begin testing your Section 111 files.
The Account Manager will be the administrative contact for the RRE and control the
overall account profile. Users associated with the reporting entity’s account will be able
to submit test and production files, maintain account information and monitor the status
of file processing using the COBSW.
25
Information Needed to Register
Each applicable, responsible reporting entity (RRE) must complete the registration
process regardless of whether an agent will be submitting files on that entity’s behalf. An
agent cannot complete the registration form for you. See
https://www.cms.hhs.gov/MandatoryInsRep/Downloads/RegistrationOverview.pdf for the
information that will be collected.
Each RRE’s registration must correspond with the manner in which it will submit files to
comply with the Section111 requirements. A separate registration must be submitted for
each file transmission set-up. For example, if an RRE is a company comprised of three
subsidiaries with separate Group Health Plan (GHP) enrollment systems for which it
intends to submit three separate sets of files, it must complete three separate
registrations and will be assigned three separate Section 111 Reporter IDs. Alternatively,
if that same company will be submitting one file that includes data for all three
subsidiaries, then it must complete only one registration and will receive one Section 111
Reporter ID.
26
7.1.7 Differences Between VDSA/VDEA and Section 111 Files
Responsible Reporting Entities (RREs) that are current VDSA/VDEA partners will note
the following differences between VDSA/VDEA and Section 111 data exchange
reporting:
•
Each Section 111 RRE will be assigned a Section 111 Reporter ID number. This
number will replace the partner's existing VDSA or VDEA ID number. The RRE
Reporter ID will be entered in Field 2 of the Header and Trailer Files for the
Section 111 GHP MSP, Non-MSP, and TIN Reference Input Files. The partner's
previous VDSA or VDEA ID will no longer be valid or used in these files.
NOTE: For the time being, a former VDSA or VDEA partner that uses the Query
Only File labeled Section 111 Query Only Input File (ANSI X12 270/271
Entitlement Query Flat File Format) must continue to use its current VDSA or
VDEA ID in Field 2 of the Query Only File Header and Trailer records. The
Section 111 Query Only File will be modified at a later date to include the new
Section 111 Reporter ID, and all RREs will be notified.
•
Pseudo-TINs for employer EIN reporting will no longer be permitted for inclusion
on the MSP Input File and TIN Reference File as of January 1, 2010. All former
VDSA/VDEA partners who have transitioned to Section 111 RREs must provide
valid TINs for employers on all file type submissions January 1, 2010 and
subsequent. RREs must send correct employer TINs in an updated TIN
Reference File with their First Quarter 2010 submissions or prior. RREs must
also submit MSP Input File update records with valid employer TINs to correct
previously submitted records with pseudo-TINs at that time. Valid insurer TINs
must be submitted on the TIN Reference File starting January 1, 2009. PseudoTINs are not permitted under any circumstances for insurer TINs.
•
Effective January 1, 2009 through December 31, 2010, on the MSP Input File,
the age threshold for reporting individuals not otherwise known to be Medicare
beneficiaries is 55 years of age and older. Effective with files submitted January
1, 2011 and subsequent, this age threshold for reporting individuals not
otherwise known to be Medicare beneficiaries will be 45 years of age and older.
For Section 111 reporting, adherence to these reporting age thresholds is a
requirement.
•
A "Small Employer Exception (SEE) HICN" field has been added; see Field 32 on
the MSP Input File Detail Record. Data supplied in new Field 32 and existing
Field 16 will be used in conjunction with records of previously approved small
employer exception requests to ensure that we know when Medicare is primary
for a particular beneficiary with the exception. A full explanation of the "Small
Employer Exception" is provided in a later section of this guide.
•
A "SEE Response Code" field has been added to the MSP Response File at
Field 81. The full explanation of the "SEE Response Code" is provided in a later
section of this guide.
27
•
A "Late Submission Indicator" field has been added on the MSP Response File.
It will be filled if the submitted record was not received within its required
submission period. The “Late Submission Indicator” is at Field 82.
•
Compliance Flag fields have been added on the MSP Response File in Fields
83-92. These flags are explained in a later section of this guide.
•
For Section 111 production file exchange, each current VDSA or VDEA partner
will be assigned a new file submission schedule. It will replace the file submission
schedule a partner is using in the Voluntary program.
NOTE: If the GHP coverage period for an Active Covered Individual was previously
submitted under VDSA/VDEA reporting and an MSP occurrence was created, a former
VDSA/VDEA RRE does not need to resubmit that record for Section 111 unless updates
are needed.
7.1.8 File Submission Timeframes
MSP Input and TIN Reference Files must be submitted on a quarterly basis during your
assigned file submission timeframe. You will receive your file submission timeframe
assignment on your profile report which is sent after the COBC has processed your
Section 111 registration. 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 COBC system when the batch
cycle runs. The COBC 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 COBC system will not mark the receipt date until the
COBC 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 time to submit your file.
You should be ready to transmit your files to the COBC on the first day of your
submission timeframe to be compliant with Section 111 reporting requirements.
There is no submission timeframe associated with Query Only or Non-MSP Input Files.
You may start sending these files as frequently as monthly, after your production live
date, on any day of the month.
28
Quarterly MSP Input File Submission Timeframes
2nd Month
3rd Month
01 - 07 Group 1
Dates 1st Month
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
29
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. Please review the definition in Section 7.1.2, the Active Covered Individuals
section of this guide. You must include information about all Active Covered Individuals
who are at least 55 years of age and older (age 45 and older effective January 1, 2011).
You must also include information on Active Covered Individuals you know or should
know to be Medicare beneficiaries or 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 the age thresholds, information for the majority of
Medicare beneficiaries will be captured. Note that the age threshold will be lowered to 45
effective January 1, 2011.
CMS uses the information in this 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 COBC 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 your or Medicare
coverage ends. The COBC 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.
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.
An MSP Response File will be sent back to you by the COBC for each MSP Input File
you send. This is the data set transmitted from COBC 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 COBC 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.
30
MSP Input, TIN Reference and MSP 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.
7.2.2 TIN Reference File
The TIN Reference File is submitted with 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 TIN Reference File may be submitted within your MSP Input File as a
logically separated file within the same physical file, or in a completely separate physical
file. It has its own header and trailer records. It must be sent 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 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 plan sponsors that are reported in Field 21 of the MSP Input 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 and ‘Y’ for an employer pseudo-TIN. In the case of an RRE that is a selfinsured employer, the same TIN may represent the insurer and employer. In this
situation, two TIN Reference File records for the TIN should be submitted, one with a
TIN Indicator of ‘I’ and the other with a TIN Indicator of ‘E’.
Each record on the TIN Reference File consists of a business entity’s federal Tax ID
Number (TIN) and the associated business mailing address that is linked to the
particular TIN as reported in Field 21 (Employer TIN) and Field 22 (Insurer/TPA TIN) of
an MSP Input File Record. Any TIN submitted on an MSP Input record must be included
in the TIN Reference File in order for the MSP Input record to process.
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. (Note: The TIN is the same as the federal Employer
ID Number, the EIN.) 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 and recovery demands should be directed. 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 as you see
fit.
31
In addition, you must provide complete TIN information about all your employer clients.
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.
There is no response file specifically associated with the TIN Reference File. If the TIN
Reference File is found to be in error, you will be contacted by your COBC EDI Rep to
resolve issues with your TIN Reference File. If your TIN Reference File is not processed
successfully, records on your MSP Input File will be rejected with errors associated with
the Insurer TIN and/or Employer TIN fields.
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 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. Also, all TINs will be verified so it is imperative that accurate
information be provided in the file.
NOTE: For Taft-Hartley multiple employer/multi-employer plans (plans using an “hours
bank” arrangement) covering individuals who routinely work for multiple employers in a
single Section 111 reporting period, RREs should submit the plan sponsor TIN rather
than the actual employer TIN in the Employer TIN (Field 21) of the MSP Input File
record. The name, address, and EIN/TIN of the plan sponsor should then be submitted
on the corresponding TIN Reference File detail record. So that CMS can identify such
situations, the RRE must place the designation of “(PS)” after the name of the plan
sponsor in the Name (Field 2) of the TIN Reference File detail record.
7.2.2.1 Special GHP Extension For Reporting Employer TINs
CMS recognizes the fact that some GHP Section 111 responsible reporting entities
may not currently carry the Employer TIN for all of their employer clients in their
systems. You must submit the applicable Employer TIN in Field 21 on each MSP
Input File detail record and the associated employer name and address on the TIN
Reference File detail record. In order to allow you time to obtain valid employer TINs,
CMS is allowing a limited extension to the reporting requirement deadline for this
particular data element.
Records for all Active Covered Individuals must be submitted per the Section 111
reporting requirements beginning with your initial MSP Input File submission.
However, if the applicable Employer TIN is not available, RREs may submit the
record with what is referred to as a “pseudo-TIN” in Field 21. A pseudo-TIN is a 9
digit number made up by the RRE to represent an employer in lieu of a valid
employer TIN.
The following rules apply to the use of pseudo-TINs for all GHP RREs:
•
Pseudo-TINs are allowed only for employer TINs on files submitted from
January 1, 2009 through December 31, 2009.
32
•
•
•
•
A record is to be submitted on the TIN Reference File for all pseudo-TINs
used in Field 21 of the MSP Input File records. The pseudo-TIN is placed in
Field 1 of the TIN Reference File record. A value of ‘Y’ must be placed in the
TIN Indicator (Field 8) of the TIN Reference File record. A valid name and
address for the employer must be placed in Fields 2-7 of the TIN Reference
file record.
Pseudo-TINs may only be used for employer TINs. Insurer TINs cannot be
pseudo-TINs. You may not use a pseudo-TIN in Field 22 of the MSP Input
File detail record. If an MSP Input record is submitted with a pseudo-TIN in
Field 22, the COBC will return a compliance flag in the corresponding MSP
Response File record. The record will be processed but the RRE will be
considered out of compliance with Section 111 reporting requirements. The
compliance flags are explained in a later section of this guide.
Starting with file submissions January 1, 2010 and subsequent, RREs must
have valid TINs for all employers. RREs must send correct employer TINs in
an updated TIN Reference File. They must also submit MSP Input update
records with valid employer TINs in Field 21 in place of the pseudo-TINs
previously submitted.
Starting January 1, 2010, the COBC will return a compliance flag on MSP
Input records submitted with pseudo-TINs in the employer TIN field. The
record will be processed but the RRE will be considered out of compliance
with Section 111 reporting requirements. The compliance flags are explained
in a later section of this guide.
7.2.2.2 TIN Validation
This section outlines the steps the COBC will take to validate TINs on the MSP Input
File and associated TIN Reference File. Note that full MSP Response File
processing and compliance flags are explained in more detail in a later section of this
guide.
Employer TINs
•
•
•
•
An employer 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’ or ‘Y’.
If no matching TIN Reference File record is found, the MSP Input record will
be rejected with an ‘SP’ disposition code and errors associated with invalid
employer information.
If a match is found with a TIN Indicator of ‘E’ then the TIN must be a valid
IRS-assigned tax ID. If the TIN is not valid, then the MSP Input record will be
processed but a compliance flag will be set on the corresponding MSP
Response File record.
If a match is found with a TIN Indicator of ‘y’, then the TIN will be considered
valid until January 1, 2010. With files submitted after January 1, 2010, the
MSP Input record will be processed but a compliance flag will be set on the
corresponding MSP Response File record.
33
Insurer TINs
•
•
•
•
An insurer 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’.
If a match is found on a TIN Reference File record with a TIN Indicator of ‘y’,
then the MSP Input record will be processed but a compliance flag will be set
on the corresponding MSP Response File record.
If a match is found on a TIN Reference File record with a TIN indicator of ‘E’
or no match is found, the MSP Input record will be rejected with an ‘SP’
disposition code and errors associated with invalid insurer information.
If a match is found with a TIN Indicator of ‘I’, then the TIN must be a valid
IRS-assigned tax ID. If the TIN is not valid, then the MSP Input record will be
processed but a compliance flag will be set on the corresponding MSP
Response File record.
7.2.3 Record Matching Criteria
7.2.3.1 Individuals
To determine whether an individual is a Medicare beneficiary, the COBC must match
your data to Medicare’s. You are required to send either a Medicare Health Insurance
Claim Number (HICN) or the individual’s Social Security Number (SSN) on your MSP
Input File records. For matching an individual to determine if they are a Medicare
beneficiary the COBC uses:
o
o
o
o
o
HICN or SSN
First initial of the first name
First 6 characters of the last name
Date of birth (DOB)
Gender (Sex).
First the COBC must find an exact match on the SSN or HICN. 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 correct HICN to use going forward on all update and delete transactions.
You should store this HICN on your internal files and use it on future transactions.
7.2.3.2 MSP Occurrences
MSP occurrences created and stored by the COBC for Medicare claims processing are
keyed by:
o
o
o
o
o
HICN
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.)
34
The COBC will use this criterion 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 is
what you provide on your input file. The MSP Type is generated by the COBC and
depends on the reason the beneficiary is entitled to Medicare and why the GHP
coverage is primary. You should (but are not required) send the HICN that the COBC
sends back on the response file on all 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. Nonetheless, 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. However, 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 parttime employees.
In order for an MSP SEE to exist, the multi-employer GHP must request and the Centers
for Medicare & Medicaid Services’ (CMS) Coordination of Benefits Contractor (COBC)
must approve the requested 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’ COBC 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.
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
35
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:
•
If reporting on an active covered individual for whom a SEE has been granted,
place the individual’s HICN in MSP Input File Field 32, Small Employer Exception
HICN. If the COBC can match this to its records using the SEE HICN, employer
EIN, and insurer policy number, the insurance effective date from the submitted
MSP file will be compared to the SEE start and end dates.
•
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 (HICN, EIN, Policy Number) 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 HICN 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.
Please refer to www.cms.hhs.gov/EmployerServices/05_smallemployerexception.asp for
more information on applying for a SEE.
36
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 conditions that must be met in order for a
patient to receive Medicare benefits and coverage for an ESRD diagnosis. Refer to
http://www.cms.hhs.gov/ESRDGeneralInformation/
http://www.cms.hhs.gov/OrigMedicarePartABEligEnrol/06_PartAEligibilityforEndStageRenalDisease(ESRD).asp and
http://www.cms.hhs.gov/EmployerServices/04_endstagerenaldisease.asp for more
information related to the coordination of benefits with Medicare for ESRD.
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.
53
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 who were enrolled in your plan as of
January 1, 2009 and subsequent. Information must be supplied for individuals whose
GHP coverage effective date was prior to January 1, 2009 if that coverage was still in
effect as of January 1, 2009. 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 who have enrolled in your plan(s) subsequent to January 1, 2009 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 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 supplied 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 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 with your initial MSP Input File submission.
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) that are now Active Covered Individuals,
changes to previously submitted records, corrections to previously submitted records,
and updates to report on a coverage termination date.
37
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, 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.
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 COBC 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 an ‘01’ disposition code in
your MSP Response File you receive back from the COBC. 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 Input File. Although he
had health insurance as a covered benefit through his employer, Mr. Smith was not
yet 55 years of age. Mr. Smith reaches age 55. 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 55. Note that this age threshold will be lowered
to age 55 and older as of January 1, 2011.
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
COBC 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 COBC 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
until you receive a response file from the COBC 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 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 COBC for which you received an ‘01’ disposition code in your MSP Response
File.
38
To successfully update a previously added record, the COBC must be able to match
on the key fields of the MSP occurrence. Please refer to the Record Matching
Criteria section of this guide. The COBC will use this criterion for update and delete
transactions you send. You should save the HICN 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 COBC 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 a MSP occurrence was created and posted
for the individual by the COBC. On July 15th, the individual stopped working and
retired. On the next quarterly update MSP Input File, an update transaction is sent
with July 15th in the termination date. The COBC 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.
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 MSP occurrence previously posted to the
CWF or MBD by the COBC. Records accepted and added as a MSP occurrence to
the CWF or MBD receive an ‘01’ disposition code in your MSP Response File you
receive back from the COBC. If your add transaction did not result in an ’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 COBC must match on the key
fields of the MSP occurrence. Please refer to the Record Matching Criteria section of
this guide. The COBC will use this criterion for update and delete transactions you
send. You should (but are not required to) save the HICN returned to you on the
response files in your internal file so it can be used in subsequent update and delete
transactions to assure a match. Aside from the transaction type and possibly the
HICN, a delete transaction should be submitted with the same values in other fields
that were submitted on the original.
Example: A record was previously sent to the COBC 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 COBC removes the MSP occurrence from
the CWF or MBD.
How to Report a Coverage Termination Date
If coverage for an Active Covered Individual previously sent and accepted by the
COBC ends, you must send an update record with the Termination Date (Field 11).
The COBC 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
39
though Medicare was always supposed to be the primary payer, and claims will be
paid erroneously.
Correcting MSP Occurrence 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 MSP occurrences
(HICN/SSN, Effective Date, Insurance Coverage Type, or Patient Relationship), 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. This process will completely replace the previously
added MSP occurrence with the correct information.
Example: A record was previously sent with March 1 as the coverage effective date.
The COBC 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 COBC
removes the MSP occurrence with the March 1 effective date and adds the correct
MSP occurrence with an April 1 effective date.
Changing Information Used to Determine Medicare Secondary Payer
The following fields are used, in part, by the COBC 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 Coverage Election – Field 19
• 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.)
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 COBC 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
40
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 changed subsequent to the MSP occurrence being posted by the
COBC. If information changes for other fields 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.
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.
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 COBC batch
system processes it. The COBC 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.
Current GHP VDSA/VDEA partners must submit their initial production Section
111 MSP Input File during the First Quarter (January – March) of 2009 during
their assigned submission timeframe. Current VDSA/VDEA partners must submit
their registration form to the COBC by October 31, 2008 and complete testing in
time to submit their production file as specified above.
Section 111 responsible reporting entities who do not (or did not) have a
VDSA/VDEA in place with CMS must submit their initial production Section 111
MSP Input File during the Third Quarter (July – September) 2009 during their
assigned submission timeframe. They must register on the COB Secure Web site
by April 30, 2009 and complete testing in time to submit their production file as
specified above.
RREs’ initial file submissions must report on all Active Covered Individuals with
coverage as of January 1, 2009, regardless of the assigned date for a particular
RRE’s first submission.
The initial MSP Input File must contain records for all Active Covered Individuals
who had open coverage under your GHP(s) as of January 1, 2009 even if it has
since been terminated.
A TIN Reference File must be submitted with the Initial MSP Input File containing
records for each TIN or EIN submitted in Fields 21 and 22 of the MSP Input File.
Subsequent MSP Input Files do not need to be accompanied by a TIN Reference
File unless there are changes to previously submitted TIN information or new
TINs have been added.
All TINs (or EINs) on the MSP Input File records must have a corresponding TIN
record on the TIN Reference File.
41
•
•
•
•
•
•
•
•
•
The initial MSP Input File must contain records for all Active Covered Individuals
who have active coverage under your plan as of the date of 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.
Subsequent quarterly update files must include records for any Active Covered
Individual 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, 2010, and
your file submission period for the second quarter of 2010 is June 1-7, 2010, then
you may delay reporting that individual until your third quarter file submission
during September 1-7, 2010. However, if the individual’s GHP coverage effective
date is April 1, 2010, then you must include this individual on your second quarter
file submission during June 1-7, 2010. 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 for more information.
Quarterly update files must contain resubmission of any records that received the
Disposition Codes ‘ID’, ‘51’ or ‘55’ on the previous response file, if the individual
is still covered and an Active Covered Individual, with corrections applied as
needed. Please refer to the Processing Response Files section for more
information.
If you have no new information to supply on a quarterly update file, you must
submit an “empty” MSP Input File with a header record, no detail records, and a
trailer record that indicates a zero detail record count.
E-mail notifications will be sent to the Section 111 responsible reporting entity
contacts after a file has been initially processed 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 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.
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
42
•
•
•
•
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. Employer size
must be calculated once per calendar year. Refer to 42 C.F.R. Part 411.101 and
42 C.F.R. Part 411.170 for details on this calculation.
A Flexible Savings 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.
The CMS considers a Health Reimbursement Account (HRA) to be a GHP
product for MSP purposes. RREs are required to include HRA programs in
Section 111 reporting.
Routine dental services and dentures are not covered benefits in the Medicare
program although 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, dental and vision
care GHP coverage are not to be included in Section 111 reporting. However,
RREs are responsible for being aware of situations where dental or vision care
services are covered by Medicare and pay primary to Medicare for all
beneficiaries who have such stand-alone coverage when appropriate.
7.2.8 Special GHP Reporting Extension For Dependents
CMS recognizes the fact that some GHP Section 111 responsible reporting entities may
not currently carry the Social Security Number (SSN) for spouses and family members in
their systems. You must send either the SSN or HICN for individuals on each detail
record. In order to allow you time to obtain the SSN or the Medicare Health Insurance
Claim Number (HICN) of Active Covered Individuals who are covered as dependents,
CMS is allowing a limited extension to the reporting requirement deadline for these
individuals.
RREs must have Social Security Numbers (SSNs) for all spouses and other family
members who are Active Covered Individuals, in addition to having SSNs for the
subscribers. RREs must submit the SSNs for all spouses and family members who are
Active Covered Individuals and whose initial date of coverage is January 1, 2009, or
later, in their initial file submission for Section 111 reporting and all subsequent
submissions. However, RREs have until their file submission in the first quarter of 2011
to submit records with the SSNs for spouses and other family members who are Active
Covered Individuals and whose initial date of coverage was prior to January 1, 2009.
CMS considers the term “family member” to include any individual covered by the plan
because of his/her association with the employed individual.
43
The extension is provided to all Section 111 GHP responsible reporting entities during
10/1/2008 to 12/31/2010. It is intended to allow you time to obtain the SSN or HICN of
spouses and family members. It does not apply to reporting subscriber information
under any circumstances. You must have the SSN or HICN for subscribers at the start
of Section 111 reporting and submit coverage information for Active Covered Individuals
who are subscribers on your initial and all subsequent update MSP Input Files.
As of 1/1/2011, GHPs that were not reporting all required dependent coverage
information must do so in their First Quarter (January – March) 2011 file. This report is to
be retroactive and include all dependents with coverage effective dates prior to 1/1/09,
and who were still active on 1/1/09.
For example, if you cover a spouse of a subscriber whose GHP coverage effective date
was 1/1/2006, his coverage is still active as of 1/1/2009, but you do not have his SSN or
HICN on file, you may delay reporting on this spouse until First Quarter 2011. However,
if you cover a spouse whose GHP coverage effective date is 2/1/2009, you must obtain
his SSN or HICN and report on this individual in your initial MSP Input File. The
extension does not apply to spouse/family members whose initial GHP coverage
effective dates are 1/1/09 or later.
44
7.2.9 Processing Response Files
For every MSP Input File you send to the COBC for Section 111 reporting, the COBC
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
(explained in a later section) 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 COBC, the disposition and error codes which let
you know what the COBC did with the record, as well as new information, such as
Medicare entitlement and enrollment data, regarding the covered individuals themselves.
You must develop processing to react to the response file. Disposition, SP and Rx error
codes are shown in Appendix D.
7.2.9.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 a ‘SP’ disposition code must be corrected and
resent on your next quarterly submission.
If a record was rejected with a disposition code of ‘51’ or ‘55’ which indicate 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.).
A disposition code of ‘51’ will also be returned if neither a HICN nor SSN is
submitted on the input record. You must obtain a valid HICN or SSN for the
Active Covered Individual and resubmit the record on your next quarterly file
submission.
Records accepted with an ‘01’ disposition code have been added by the COBC
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 COBC based on Medicare’s information and could be used
to update your internal files:
o
o
o
o
HICN
Active Covered Individual/Beneficiary Name
Date of Birth
Gender
45
o
SSN
In addition, records returned with an ‘01’ disposition code will contain the
following information which you may use in your claims processing for
coordination of benefits and proper claim processing:
o
o
o
•
•
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, and C Coverage Dates
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 55 (age 45 as
of January 1, 2011) 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 an ‘01’ disposition code, the GHP coverage is terminated or the
individuals no longer fit the definition of Active Covered Individuals.
7.2.9.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 “COBC Responsible”. There are
some errors that an RRE cannot fix, such as those related to conflicting data on
internal Medicare databases.
Since the COBC must send records to other Medicare databases to post the MSP
occurrences, errors beyond your control can occur. Usually the COBC 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.
Some SP error codes received on you MSP Response File may be due to errors on
your TIN Reference File. If there is an error in a TIN or an insurer name or address
submitted on a TIN Reference File, you will see the associated SP error codes
posted on your corresponding MSP records. In order to correct these errors, you will
need to resubmit an updated TIN Reference File with your next quarterly MSP Input
File submission.
46
Special Consideration for the SP ES 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.
The COBC 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. In these situations, the COBC 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 an ‘01’ disposition code is
returned. Since the employer size may not change, you may continue to receive a
response record back with a SP disposition and SPES error code for these
situations.
Special Consideration for Non-Overlapping GHP and Medicare Coverage
If the Active Covered Individual you submit on a 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/2009 to 3/31/2009 and Medicare coverage begins on 4/1/2009. 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. 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.
This situation applies only to add records. If you receive a SP32/SP62 error on an
update record you are sending to apply a termination date to a previously added
MSP occurrence (your GHP coverage has ended), then you most likely have an error
47
in your system that needs to be addressed. Please see the description of SP error
codes in Appendix D.
7.2.9.3 Rx Disposition and Rx Error Codes
If you are reporting under the Expanded Option, you will send primary prescription
drug coverage on your MSP Input File. Prescription drug information can be sent as
part of a combined coverage record with hospital and/or medical coverage (Input
Field 8 Coverage Types V, W, X, Y, 4, 5, 6) or as a separate coverage record for
drug-only (Input Field 8 Coverage Types U 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 a MSP occurrence for prescription drug coverage that is
primary to Medicare Part D is:
o
o
o
o
o
HICN
MSP Effective Date (later of GHP drug coverage effective date or Part D
Enrollment Date)
Patient Relationship Code (self, spouse, dependent, etc.)
Section 111 Reporter ID (supplied on your header record)
Insurance Coverage Type (Comprehensive hospital/medical/drug, Drug
Only Network Drug, etc.)
The COBC 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, 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, you must examine:
48
•
•
•
•
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, 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 a ‘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’, ‘51’ or ‘55’
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 an ‘01’ Rx disposition code have been added by
the COBC 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 COBC and could be used to update
your internal files:
o
o
o
o
o
HICN
Active Covered Individual/Beneficiary Name
Date of Birth
Gender
SSN
In addition, drug records returned with an ‘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:
o
o
o
•
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
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.
49
7.2.9.4 Expanded Option Only - Part D Eligibility and Enrollment Data
For those reporting under the Expanded Reporting Option only, the MSP Response
Files contain five related fields that can have information about current Medicare Part
D eligibility and enrollment. These fields will be left blank on MSP Response File
records for those reporting 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.
The beneficiary’s current Part D Plan is identified in Current Medicare Part D Plan
Contractor Number (Field 57).
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.9.5 File Level and Threshold Errors
After completion of data quality edits, the COBC will check your MSP Input File to
ensure it does not exceed any threshold restrictions. The file threshold checks
include:
• 10% or more of the total records are delete transactions
• 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 COBC EDI Rep. An e-mail will be sent to
your contacts named during registration to inform them of this suspension. You must
contact your assigned EDI Rep to discuss and resolve file threshold errors. Your file
50
may be released for processing or, if sent in error, deleted by your EDI Rep in which
case you must resend a corrected file for the quarter.
7.2.9.6 Late Submission and Compliance Flags
The MSP Response File contains indicators or flags that provide information on
issues related to reporting requirement compliance. These flags are different from
error codes. Unlike an error code, a record will not be rejected if one of the
conditions to set the indicators is found on the record. Instead, the record is
processed and an MSP occurrence posted if applicable. However the COBC will set
the flags, track this information, and include it on compliance reports. The flags
provide the RRE notice that the submitted record was not in compliance with Section
111 reporting requirements. You must review these flags, apply corrections to your
internal system or data used for Section 111 reporting, and resubmit records with
corrections, when applicable.
The first such field on the MSP Response File is the Late Submission Indicator in
Field 82, which 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 older than 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 COBC 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.
Following the Late Submission Indicator are a set of ten two-byte Compliance Flags
in Fields 83-92. The possible values that could be posted in these flags are
documented in the Compliance Flag Code table in Appendix D. If no compliance
issue is found with the record, all the Compliance Flags on the response file record
will be blank. If only one issue is found, then the corresponding code will be placed in
51
the first flag. If additional issues are found with the same record, then the
corresponding compliance code will be placed in the second and subsequent flags
(the first available flag field).
For example, if an MSP Input File record is submitted with an employer TIN that
matches a TIN submitted on the TIN Reference File but that TIN could not be
validated by the COBC, then the record will be processed and an MSP occurrence
created if applicable, but the corresponding MSP Response File record will contain a
value of ‘02’ in Compliance Flag 1 (Field 83). The COBC will consider the TIN invalid
if it cannot be matched to a valid IRS tax identification number or employer
identification number (EIN) or if the TIN was submitted on the TIN Reference File as
a pseudo-TIN (value of ‘Y’ in the TIN Indicator field) after January 1, 2010. A similar
compliance check is applied to the insurer/TPA TINs submitted on the MSP Input
File. The COBC will place a compliance code of ‘01’ in the first available Compliance
Flag when an insurer TIN cannot be validated or if the TIN was submitted on the TIN
Reference File as a pseudo-TIN. When either of these codes is received back in a
Compliance Flag on a response record, you must obtain the valid TIN and resubmit
the record as an update transaction on your next quarterly file submission. At the
same time, the valid TIN and TIN Indicator must also be submitted on an updated
TIN Reference File record.
7.2.9.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 COBC 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.
7.2.9.8 End Stage Renal Disease (ESRD)
In order to allow Section 111 reporting entities to better coordinate benefits for
Medicare beneficiaries related to End Stage Renal Disease (ESRD), the COBC 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 SelfTraining Date, the most recent Kidney Transplant Date, and the most recent Kidney
Transplant Failure Date. Please refer to response file fields 75-80 in the file
specifications in Appendix A.
52
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 Part A entitlement and Parts B and C enrollment of potential
Medicare beneficiaries. Note that this file does not currently provide Medicare Part D
enrollment information. 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 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 COBC) 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 COBC. The COBC 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 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.
During registration for Section 111 reporting, you will be asked to indicate whether you
wish to use the HEW software. If you choose that option, your assigned COBC EDI Rep
will provide you with a copy of the software. Mainframe and PC/Server-based versions of
the HEW software are available.
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, please contact your
EDI Rep for the necessary mapping documents.
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.
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 month. These
files do not have to be submitted during a specific submission timeframe.
Only Medicare Part A, Part B and Part C coverage information will be supplied on
the Query Only Response File. Part D coverage information will be added at a
54
•
•
•
•
7.4
later date but only provided to those reporting under the Expanded Reporting
Option.
Query Only Response Files will be returned to you within 14 days.
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 e-mail notification and are to contact your EDI Rep to address the
identified errors. Files failing for these errors must be corrected before they can
be processed.
o File does not contain a header record
o Header record does not contain a valid Section 111 Reporter ID
o File does not contain a trailer record.
E-mail notifications will be sent to the Section 111 responsible reporting entity
contacts after the file has been received and when a response file has been
transmitted or is available for download.
Query Only Response Files will be returned with NO header and trailer records.
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 COBC 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 NonMSP 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 COBC 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 beneficiary’s Medicare entitlement, enrollment in Part D, and your
coverage dates. A supplemental Part D record will have an open end date if both your
coverage and Medicare coverage are active. An end date is applied when either your or
Medicare coverage ends.
55
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 a RDS
retiree file record. If that record is accepted by the COBC 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 COBC 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 COBC
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.
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 field 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.
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
56
the individual as well as information about whether the supplemental drug record
was accepted and posted by the COBC 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 COBC must match
your data to Medicare’s. You are required to send either a Medicare Health
Insurance Claim Number (HICN) or the individual’s Social Security Number (SSN) on
your Non-MSP Input File records. For matching an individual to determine if they are
Medicare beneficiary the COBC uses:
o
o
o
o
o
HICN or SSN
First initial of the first name
First 6 characters of the last name
Date of birth (DOB)
Gender (Sex)
First the COBC must find an exact match on the SSN or HICN. Then at least 3 out of
the four remaining criteria must be matched exactly. If a match is found, you will
always be returned the correct HICN to use going forward on all update and delete
transactions. You should store this HICN on your internal files and use it on future
transactions.
7.4.3.2 Supplemental Prescription Drug Records
Supplemental drug coverage records created and stored by the COBC for Medicare
claims processing are keyed by:
o
o
o
HICN
Supplemental Coverage Effective Date
Coverage Type (network drug only, comprehensive hospital/medical/drug,
etc.)
57
o
o
Patient Relationship Code (self, spouse, dependent, etc.) and
Section 111 Reporter ID
The COBC will use this criterion for subsequent update and delete transactions you
send. You should (but are not required) send the HICN that the COBC sends back
on the response file on all 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 were enrolled in your plan as of January 1, 2009 and subsequent.
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 who have
enrolled in your plan(s) subsequent to January 1, 2009 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 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 anytime 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
58
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 below. 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.
Non-MSP File Structure
Header Record for N/D Record File
N Record
D Record
D Record
D Record
Trailer Record for N/D Record File
Header Record for RDS Application 1
S Record
S Record
Trailer Record for RDS Application 1
Header Record for RDS Application 2
S Record
S Record
S Record
Trailer Record for RDS Application 2
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.
59
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 COBC has not
posted to the Medicare Beneficiary Database (MBD). D records accepted and added
as supplemental drug coverage to the MBD receive an ‘01’ D/N disposition code
(Field 48) in your Non-MSP Response File you receive back from the COBC. 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 an ‘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 of this guide. The COBC will use this criterion for update and delete
transactions you send. You should save the HICN returned to you on the response
files in your internal files so it can be used in subsequent update and delete
transactions.
Delete Transactions
A “delete” record or transaction is defined with a ‘1’ in the Transaction Type (Field
21). A delete transaction is sent to remove a supplemental drug or subsidy record
previously posted to the MBD from an add transaction. If your add transaction did not
result in an ’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 COBC must match on the key
fields of the supplemental drug or subsidy record. Please refer to the Record
Matching Criteria section of this guide. The COBC will use this criterion for update
and delete transactions you send. You should save the HICN returned to you on the
response files in your internal file so it can be used in subsequent update and delete
transactions to assure a match.
60
How to Report a Coverage Termination Date
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). The
COBC 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.
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 COBC, 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.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 COBC has
received a response from the RDS Center.
61
•
•
•
•
•
•
•
The initial Non-MSP Input File must contain D records for all Inactive Covered
Individuals who had open prescription drug coverage under your GHP(s) as of
January 1, 2009 even if it has since been terminated.
The initial Non-MSP Input File should contain D records for all Inactive Covered
Individuals who 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 for more information.
Update files must contain resubmission of any records that received Disposition
Codes ‘ID’, ‘51’ or ‘55’ on the previous file submission response with corrections
applied as needed. Please refer to the Processing Response Files section for
more information.
E-mail notifications will be sent to the Section 111 responsible reporting entity
contacts when the file has been received and when a response file has been
transmitted or is available for download.
7.4.7 Processing Response Files
For every Non-MSP Input File you send to the COBC for Section 111 reporting, the
COBC 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 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 COBC, the disposition and error codes which let you
know what the COBC 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.
62
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.
The beneficiary’s current Part D Plan is identified in Current Medicare Part D Plan
Contractor Number (Field 41).
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.
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 a ‘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 a N/D disposition code of ‘ID’, ‘51’ or ‘55’ which
indicate 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 HICN nor
SSN was submitted on the input record. You must obtain a valid HICN or
SSN for the individual and resubmit the record in your next file submission.
Records accepted with an ‘01’ N/D disposition code have been added by the
COBC 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 COBC based on Medicare data and could be
used to update your internal files:
63
o
o
o
o
o
SSN
HICN
Inactive Covered Individual/Beneficiary Name
Date of Birth
Gender
In addition, records returned with an ‘01’ disposition code will contain the following
information which you may use in your claims processing for coordination of benefits
and proper claim processing:
o
o
o
o
o
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
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 a ‘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’, ‘51’ or ‘55’ which
indicate 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 an ‘01’ N/D disposition code have been matched by
the COBC 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 COBC based on Medicare data
and could be used to update your internal files:
o
o
o
o
o
SSN
HICN
Inactive Covered Individual/Beneficiary Name
Date of Birth
Gender
N records returned with an ‘01’ disposition code will contain the following
information which you may use in your claims processing for coordination of
benefits and proper claim processing:
64
o
o
o
o
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.7.5 Non-MSP Input File Level and Threshold Errors
After completion of data quality edits, the COBC will check your Non-MSP Input File
to ensure it does not exceed any threshold restrictions. The file threshold checks
include:
•
•
•
10% or more 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
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 COBC EDI Rep. An e-mail will be sent to
your contacts named during registration to inform you of this suspension. You must
contact your EDI Rep to discuss and resolve file threshold errors. Your file may be
released for processing or, if sent in error, deleted by your EDI Rep in which case
you may resend a corrected file.
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 COBC 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
http://www.cms.hhs.gov/ESRDGeneralInformation/
65
http://www.cms.hhs.gov/OrigMedicarePartABEligEnrol/06_PartAEligibilityforEndStageRenalDisease(ESRD).asp and
http://www.cms.hhs.gov/EmployerServices/04_endstagerenaldisease.asp for more
information related to the coordination of benefits with Medicare for ESRD.
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
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 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: 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: 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:
http://rds.cms.hhs.gov/.
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.
66
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 below. Do not put N
and D records on a Non-MSP File containing S records.
Non-MSP File Structure for RDS Retiree Files
Header Record for RDS Application 1
S Record
S Record
S Record
S Record
Trailer Record for RDS Application 1
Header Record for RDS Application 2
S Record
S Record
Trailer Record for RDS Application 2
Header Record for RDS Application 3
S Record
S Record
S Record
Trailer Record for RDS Application 3
The COBC 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 COBC will populate the S response record with Medicare Part A, B, C and D
coverage information as applicable. The COBC 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
67
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 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 COBC 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-48 (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
http://rds.cms.hhs.gov/.
Converting an “S” Record to a “D” Record
Prior to transmitting the Non-MSP Response File back to you, when the COBC
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 COBC 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 COBC 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.
68
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 4). The following is a table
providing the RDS Reason Codes you may receive on an unsolicited response. 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 periods for
claiming the subsidy for affected individuals using this information or resend the
original records for proper subsidy determination.
RDS
Reason
Code
10
11
12
20
21
Description
Enrolled in Part D. The retiree cannot be covered
under the RDS program because (s)he is/was
enrolled in Medicare Part D during the coverage
period provided by the Plan sponsor.
Not eligible for Medicare. The retiree cannot be
covered under the RDS program because (s)he
is/was not enrolled/entitled to Medicare during the
coverage period provided by the Plan sponsor.
Beneficiary is deceased.
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 (s)he overrides the denial and
enrolls in Part D.
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.
69
7.5
Testing the Section 111 Reporting Process
All Section 111 GHP responsible reporting entities must test both file transmission and
processing for all applicable file types prior to submitting production files. For the initial
Section 111 GHP reporting process implementation, testing will be performed in the
same manner as was done for the earlier voluntary data sharing program. For April
2009, the COBC will modify the testing requirements and add testing and tracking
functionality to the COB Secure Web site. This guide will be updated for the new testing
requirements at a later date.
Overview of the Testing Process
Before transmitting your first “live” (full production) input file to the COBC, you must
thoroughly test the file transfer process. Prior to submitting your initial MSP Input File,
you will submit a test initial MSP Input File, including a test TIN Reference File. If you
have chosen the Expanded Reporting Option, you will also send a test initial Non-MSP
Input File. The COBC will return a test initial MSP Response File and a test initial NonMSP Response File. The response files will indicate what errors were found and the
COBC will work with you to correct them. You must continue to submit your initial test
files until these errors are corrected. Following a successful submission of your initial
files, you will send test update MSP and Non-MSP Input Files. Testing will be completed
when you have successfully added new enrollees using test update MSP and Non-MSP
Input Files and you and the COBC agree all testing has been satisfactorily performed.
Detailed Testing Process
You and the COBC will begin testing as soon your registration form has been processed,
you receive your profile report via e-mail, and you return your signed profile report to the
COBC. All administrative and technical arrangements for sending and receiving test
files will be made during the registration process.
The population size of a test file may not exceed 100 records.
You will be assigned a COBC Electronic Data Interchange Representative (EDI Rep)
during registration. Your EDI Rep will be your main point of contact for testing Section
111 reporting with the COBC and will help you with questions and issues throughout the
process. Your profile report will contain contact information for your assigned EDI Rep.
You must test each applicable file type you will be exchanging before submitting any
production files. Basic Reporting Option submitters must test the MSP Input File and,
optionally, the Query Only Input File. Expanded Reporting Option submitters must test
the MSP Input File, Query Only Input File (optional) and the Non-MSP Input File.
Testing for the MSP Input File should be completed first. If you choose not to use the
Query Only File in production, you do not have to perform testing for it. However, if you
do not perform successful testing of the Query Only Input File you will not be allowed to
submit it in production.
70
Testing MSP and Non-MSP Input Files: The test file record layouts used will be the
standard MSP and Non-MSP record layouts found in the appendices of this guide.
Data provided in test files will be kept in a test environment by the COBC, and will
not be used to update the Medicare CWF or MBD.
You will submit an initial test file with all add transactions. You will submit a test TIN
Reference File with your initial test MSP Input File. Upon completion of its review of
your initial test file, the COBC will provide you with a response for every record found
on it usually within a week after receipt of the test file. After receiving the initial test
response file in return, you will take the steps necessary to correct the problems that
were reported on it and resubmit the initial test file as necessary.
After the initial test files are successfully processed, you must create and submit an
update test file for each file type. The update test file should contain new add records
as well as updates and deletes for records sent and accepted on the initial test file.
Your update test MSP Input File should be accompanied by a full TIN Reference File
as needed. Upon completion of its review of the update test file, the COBC shall
provide you a test response file within a week after receipt of the test file. After
receiving the update test response file in return, you will take the steps necessary to
correct problems that were reported on it and resubmit the update test file as
necessary.
MSP and Non-MSP Input Test Files must be limited to 100 records.
After all file transmission testing has been completed to the satisfaction of both you
and the COBC, you may begin submitting your regular production files.
Testing Query Only Input Files: You will provide the COBC a test file of the data
elements in Appendix B for the Query Only Input File. The HIPAA mandates that
you must be able to transmit and receive the Query Only Files in the ANSI X12
270/271 (Health Care Medicare Entitlement/Benefit Inquiry and Information
Response) transaction code set rules and standards. The COBC will provide you
with a copy of the HIPAA Eligibility Wrapper (HEW) software if requested or you may
use your own ANSI X12 translator.
The Query Only Input Test File shall contain a maximum of 100 records of actual
data on covered individuals. The Test File will allow the COBC to review the data
prior to receiving your first Query Only File submission and identify any defects. You
may provide a test Query Only File to the COBC as soon as possible after the
registration process has been completed.
After processing the Test File, the COBC will provide you a test Query Only
Response File identifying those covered individuals that have Medicare coverage,
and those individuals not found to be Medicare beneficiaries. The COBC will return
the Response File to you within a week of receipt of the Test File. The COBC will
request that you submit another Query Only Input Test File if we find it necessary.
After both you and the COBC are satisfied with the results of the testing, you may
begin submitting regular production files.
Former VDSA/VDEA Partners Only: Since this file is in the same format as that used
for the VDSA/VDEA data exchange, if you have successfully tested with it in the
71
past, you are not required to re-test this file for your initial Section 111 data
submission.
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 including file transmission information. Current VDSA
partners must submit the registration found on
www.cms.hhs.gov/MandatoryInsRep and submit it to the COBC by October 31,
2008. All others are to complete registration on the COB Secure Web site
(COBSW) between April 1, 2009 and April 30, 2009.
• Receive your profile report via e-mail indicating your registration was accepted by
the COBC.
• Verify, sign and return your profile report to the COBC.
• Complete your file transmission set up. If you choose SFTP/HTTPS, set up your
CMS mailbox. If you already have a mailbox for VDSA/VDEA, you will use that
and will not need a new one. If you choose Connect:Direct (AGNS) establish a
connection to AGNS, if you don’t have one yet, 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 COBC.
• Test each Section 111 file type you will be submitting with the COBC.
o Basic Reporting Option Submitters – MSP and optional Query Only Files.
o Expanded Reporting Option Submitters – MSP, Non-MSP, and optional
Query Only Files.
• Submit your initial 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 monthly ongoing.
• Submit your quarterly MSP Input File ongoing during your assigned submission
periods.
• Submit your monthly or quarterly Non-MSP Input File ongoing.
• VDSA/VDEA partners: When the Section 111 application is implemented on the
COB Secure Web site (COBSW) in April 2009, you will be notified. At that time,
establish your account on the site as directed and register users. You will then be
able to monitor your Section 111 processing and compliance on the COBSW.
72
8
8.1
Electronic Data Exchange
File Transmission Methods
Currently, there are three separate methods of data transmission that Section 111
responsible reporting entities may utilize. As part of your registration for Section 111,
you will indicate the method you will use and submit the applicable transmission
information. In April 2009, the COBC will add functionality for Section 111 to transmit
files via SFTP and HTTPS using the COB Secure Web site (COBSW). This guide will be
updated with that information as it becomes available.
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 using that
method.
8.1.1 Connect:Direct (NDM via the AT&T Global Network System (AGNS))
For responsible reporting entities with very large transmission volume the preferred
method of electronic transmission is Connect:Direct (formerly known as Network
Data Mover [NDM]) via the AT&T Global Network System (AGNS). AGNS is
capable of transporting multiple protocol data streams to its clients world-wide, and
uses triple DES as its encryption default. Use of either SNA or TCP/IP is available to
submitters connected to the AGNS network.
Using this method, responsible reporting entities must first establish an AGNS
account in order to send files directly to the COBC over AGNS. Section 111
responsible reporting entities that currently do not have an existing AGNS account
and plan to send and receive information using this telecommunications link should
contact one of the well-established resellers of AT&T services to obtain a dedicated
or a dial-up access line to the AGNS VAN. You are encouraged to do this as
soon as possible since this set up can take a significant amount of time.
During registration, you will provide the AGNS account and connectivity information
needed for this file transfer method as well as the dataset names you want the
COBC to use when sending back response files. After your registration has been
processed, the COBC will e-mail a profile report with the COBC VTAM information
and your Section 111 destination dataset names to which you will send your input
files. The dataset naming convention you will use to transmit files to the COBC under
this method is:
Production Files
For MSP Input/TIN Reference Files:
For Non-MSP Files:
For Query-Only Files:
PCOB.BA.MRMSP.Rxxxxxxx(+1)
PCOB.BA.MRNMSP.Rxxxxxxx(+1)
PCOB.BA.MRQRY.Rxxxxxxx(+1)
73
Test Files
For MSP Input/TIN Reference Files:
For Non-MSP Files:
For Query-Only Files:
TCOB.BA.MRMSP.Rxxxxxxx(+1)
TCOB.BA.MRNMSP.Rxxxxxxx(+1)
TCOB.BA.MRQRY.Rxxxxxxx(+1)
Where xxxxxxx – is the last 7 digits of your Section 111 Reporter ID assigned to you
after registration as shown on your profile report.
Files transmitted directly to the COBC via AGNS using Connect:Direct will be
automatically converted to EBCDIC.
8.1.2 Secure File Transfer Protocol (SFTP)
At the current time, files transmitted via SFTP are actually sent over the Internet to
the CMS Data Center; CMS then forwards them to the COBC. The responsible
reporting entity’s SFTP mailbox is located on a CMS server. Using SFTP permits
automated data transmission and management. At a later date, this transmission
method will be available on the COBSW.
For this transmission method, CMS has extensive experience using the Sterling
Connect:Enterprise Secure Client. The cost to you to acquire this software is
reasonable. However, you may use another client as long as it is SSH v2 capable.
If you are new to this method and do not currently have a CMS SFTP/HTTPS
mailbox for COBC data file exchange, your EDI Rep will contact you regarding the
process to set up your mailbox after your registration has been processed.
If you have already been using SFTP (or HTTPS) for your voluntary data sharing
program file exchange, then you will use the same CMS SFTP/HTTPS Mailbox
(organization number) and IACS (Individuals Authorized Access to the CMS
Computer Services) user IDs (UIDs or GUIDs). You will, however, need to use new
file names for Section 111. The file naming conventions are documented in
Appendix F of this guide. Files transmitted via SFTP should be compressed
and sent as .zip files.
Please refer to the following documentation on the CMS Web site. This
documentation pertains only to those registering and transmitting files prior to April
2009. All new GHP RREs registering in April 2009 will utilize the COBSW.
Documentation for SFTP via the COBSW will be provided at a later date.
•
CMS Connect: Enterprise Secure Client (SFTP) Gentran Internet Option
Manual - www.cms.hhs.gov/mmahelp/downloads/SecureFTPInternet.pdf
•
CMS Data Exchange Preparation Procedures http://www.cms.hhs.gov/mmahelp/downloads/Data_Exchange_Preparation_P
rocedures_20070407.pdf
•
IACS User Guide http://www.cms.hhs.gov/MMAHelp/downloads/IACS_UserGuide_8.1.pdf
74
•
IACS User Guide Attachment C – Coordination of Benefits http://www.cms.hhs.gov/MMAHelp/downloads/IACS_User_Guide_Attachmen
t_C_v8_20061220.pdf
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 CMS Data Center and
then CMS forwards them to the COBC. The responsible reporting entity’s HTTPS
mailbox is located on a CMS server. There is no additional cost associated with
using this method as long as the Internet Explorer (IE) browser is used. However,
use of HTTPS does not permit automated data management and is only
recommended for entities with a relatively small amount of data to submit. At a later
date, this transmission method will be available on the COBSW.
If you are new to this method and do not currently have a CMS SFTP/HTTPS
mailbox for your COBC data file exchange, your EDI Rep will contact you regarding
the process to set up your mailbox after your registration has been processed
If you are already using HTTPS (or SFTP) for your voluntary data sharing program
file exchange, then you will use the same CMS SFTP/HTTPS Mailbox (organization
number) and IACS user IDs (UIDs or GUIDs). You will however need to use new file
names for Section 111. The file naming conventions are documented in
Appendix F of this guide. Files transmitted via HTTPS should be compressed
and sent as .zip files.
Please refer to the following documentation on the CMS Web site. This
documentation pertains only to those registering and transmitting files prior to April
2009. All new GHP RREs registering in April 2009 will utilize the COBSW.
Documentation for HTTPS via the COBSW will be provided at a later date.
•
CMS Data Exchange Preparation Procedures http://www.cms.hhs.gov/mmahelp/downloads/Data_Exchange_Preparation_P
rocedures_20070407.pdf
•
IACS User Guide http://www.cms.hhs.gov/MMAHelp/downloads/IACS_UserGuide_8.1.pdf
•
IACS User Guide Attachment C – Coordination of Benefits http://www.cms.hhs.gov/MMAHelp/downloads/IACS_User_Guide_Attachmen
t_C_v8_20061220.pdf
•
HTTPS User Guide http://www.cms.hhs.gov/COBAgreement/Downloads/HTTPSGuide.pdf
75
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.
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 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, in most cases your GHP coverage is
only primary until the covered individual becomes covered by Medicare in which case
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 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 Inactive Covered Individuals.
76
If you report for Section 111 under the Expanded 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, but Part D data is not yet available on this file
layout. Part D coverage 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 Automated Status and Inquiry System (BASIS)
When a Section 111 responsible reporting entity has an immediate need to access
Medicare entitlement information, BASIS – the Beneficiary Automated Status and Inquiry
System – 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. Using a private, Web-based host,
you can use BASIS to access the information on the Medicare Beneficiary Database
(MBD) for up to 200 individuals per Section 111 Reporter ID per month. Access to
BASIS is contingent on you having submitted your initial MSP Input File.
If you selected the Basic Reporting Option for Section 111, you will only be provided with
Medicare Part A, B and C coverage information. Expanded Reporting Option submitters
will be additionally provided Part D coverage information.
In overview, BASIS operates as follows:
1. Complete and submit your BASIS Request Attachment, found in Appendix E, to
your EDI Rep.
2. The COBC assigns each responsible reporting entity its own personal
identification number (PIN) for BASIS. This number is delivered to the
designated Section 111 contact persons within 30 days of submission of your
initial MSP and receipt of your BASIS Request Attachment. At this time, you will
also receive information concerning the designated telephone line to be used for
the BASIS application.
3. The COBC will notify you when the BASIS application is operational and will
provide detailed instructions on how to use the BASIS application.
4. You will dial a designated telephone line to access the BASIS application, using
your assigned BASIS PIN. For each Covered Individual for whom you are
requesting Medicare entitlement information, you will enter the following data
elements that identify the subject of the query:
Social Security Number
Last Name
First Initial
Date of Birth
Gender
5. The COBC will display the results of the inquiry in BASIS in real time while you
are logged into the application.
77
10 Data Use Agreement
As part of the Section 111 registration process, each Section 111 responsible reporting
entity will be asked to sign a copy of the following Data Use Agreement. 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 responsible reporting
entities who provide other health insurance coverage. Measures must be taken by both
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
defined above, certify that the information contained in this Registration Form 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. § 1395k(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 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 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 Responsible Reporting Entity 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
Responsible Reporting Entity 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.
78
11 COB Secure Web Site
A new application will be developed on the Medicare COB Secure Web site (COBSW) to
support Section 111 reporting. The functionality for this application will be implemented
at a later date and this guide and the Section 111 informational page at
www.cms.hhs.gov/MandatoryInsRep/ will be updated with information on that as it
becomes available. The initial functionality is slated to be available starting in April 2009.
On the COBSW, Section 111 reporters will be able to:
• Complete the registration process. All information will be 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 COBC data center without
going through the CMS data center.
• 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.
12 Customer Service and Reporting Assistance
Please be sure to visit the Section 111 page on the CMS Web site
www.cms.hhs.gov/MandatoryInsRep frequently for updated information on Section 111
reporting requirements including updates to this guide. In order to be notified via e-mail
of updates to this page, click on the “For e-mail updates and notifications” link and add
your e-mail address to the distribution list for these updates.
12.1 EDI Representative
After you register for Section 111 reporting, you will be assigned a COBC EDI Rep to
be your main contact for Section 111 file transmission and reporting issues. Contact
information for your EDI Rep will be provided on your profile report.
12.2 Customer Service Center
The Coordination of Benefits Contractor's trained staff will help you with your general
Medicare COB and MSP questions. Customer Service Representatives are available
to provide you with quality service Monday through Friday, from 8:00 a.m. to 8:00
p.m., Eastern Time, except holidays, at toll-free lines:1-800-999-1118 or TTY/TDD:
1-800-318-8782 for the hearing and speech impaired. The COBC EDI Department
may be reached directly at 646-458-6740.
79
Please visit the COB Web page on the CMS Web site at
www.cms.hhs.gov/COBGeneralInformation/.
12.3 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 COBC. Your EDI Rep should always be sought out
first to help you find solutions for any questions, issues or problems you have.
If after working with your EDI Rep, you think your problem could benefit from help at
a higher level, please contact Jeremy Farquhar, at 646-458-6614. His email address
is [email protected].
If you feel further escalation is necessary, contact the COBC EDI Manager, Bill Ford,
at 646-458-6613. Mr. Ford’s email address is [email protected].
The COBC Project Director, with overall responsibility for the COBC EDI
Department, is Jim Brady. Mr. Brady can be reached at 646-458-6682. His email
address is [email protected].
13 Training and Education
Various forms of training and educational materials will be available to help you with
Section 111 in addition to this guide.
•
•
•
The Section 111 CMS Web page at www.cms.hhs.gov/MandatoryInsRep will
contain links to all CMS publications regarding the MSP Mandatory Reporting
Requirements under Section 111 of the MMSEA of 2007. In order to be notified
via e-mail of updates to this page, click on the “For e-mail updates and
notifications” link and add your e-mail address to the distribution list for these
updates.
CMS and the COBC will be conducting a series of teleconferences that will
provide information regarding Section 111 reporting requirements. The schedule
for these calls will be posted on the Section 111 Web page at
www.cms.hhs.gov/MandatoryInsRep.
CMS and the COBC will make available a curriculum of computer-based training
(CBT) courses to Section 111 RREs. These courses will provide overviews of
Medicare and MSP in addition to in-depth training on Section 111 reporting
requirements, file transmission, file formats, and file processing. Instructions on
how to sign up for these courses will be posted on
www.cms.hhs.gov/MandatoryInsRep when available.
80
Appendix A – MSP File Specifications
Section 111 GHP MSP Input File
Section 111 GHP MSP Input File Header - 425 bytes
Field
Name
Size Displacement
Data Type
Description
1.
Header
Indicator
2
1-2
Alphanumeric
Must be: ‘H0’
2.
Section
111
Reporter
ID
9
3-11
Numeric
‘000000001’, ‘000000002’,
etc. ID number assigned by
COBC.
Required.
3.
File Type
4
12-15
Alpha
4.
File Date
8
16-23
Numeric
Date
Must be ‘MSPI’ – MSP input
file.
CCYYMMDD
Required.
5.
Filler
402
24-425
AlphaNumeric
81
Unused Field – fill with
spaces.
Section 111 GHP MSP Input File Detail Record – 425 bytes
Field
Name
Size Displacement
Data Type
Description
Active Covered
Individual’s/Beneficiary’s
Health Insurance Claim
(Medicare ID) Number
(HICN).
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.
1.
HIC
Number
(HICN)
12
1-12
AlphaNumeric
2.
Beneficiary
Surname
6
13-18
Text
Active Covered
Individual’s/Beneficiary’s
Last Name – Required.
3.
Beneficiary
First Initial
1
19-19
Alpha
Beneficiary’s First Initial –
Required.
4.
Beneficiary
Date of
Birth
8
20-27
Date
Beneficiary’s DOB
(CCYYMMDD) – Required.
5.
Beneficiary
Sex Code
1
28-28
Numeric
6.
DCN
15
29-43
Text
7.
Transaction
Type
1
44-44
Numeric
82
Beneficiary’s Sex –
Required.
Valid Values:
0 = Unknown
1 = Male
2 = Female
Document Control Number;
assigned by the Section 111
GHP RRE.
Required. Each record
within the current file must
have a unique DCN.
Type of Transaction –
Required.
Valid Values:
‘0’ = Add Record
Section 111 GHP MSP Input File Detail Record – 425 bytes
Field
8.
Name
Coverage
Type
Size Displacement
1
45-45
Data Type
AlphaNumeric
Description
‘1’ = Delete record
‘2’ = Update/Change record
Type of Insurance –
Required.
Basic Reporting Option
includes Hospital and/or
Medical Coverage.
Expanded Reporting Option
includes all Coverage Types.
Valid Values:
‘J’ = Hospital Only
‘K’ = Medical Only
‘A’ = Hospital and Medical
‘U’ = Drug Only (network Rx)
‘V’ = Drug with Major Medical
(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 (nonnetwork Rx)
‘6’ = Medical and Drug (nonnetwork Rx)
When reporting coverage
under an HRA, use the code
most applicable to the
reimbursable services. For
example, if the HRA covers
only medical services, use a
value of ‘K’. If the HRA
covers only non-network
prescription drugs, use a
value of ‘Z’.
83
Section 111 GHP MSP Input File Detail Record – 425 bytes
Field
Name
Size Displacement
Data Type
Description
9.
Beneficiary
Social
Security
Number
9
46-54
Numeric
8
55-62
Date
Termination
Date
8
63-70
Date
12.
Relationship
Code
2
71-72
Numeric
13.
Policy
Holder’s
First Name
9
73-81
Text
Active Covered
Individual’s/Beneficiary’s
SSN – Required if HICN not
provided. Populate with 9
spaces if unavailable.
Start Date of Covered
Individual’s GHP Coverage
by Insurer (CCYYMMDD).
Required.
End Date of Covered
Individual’s GHP Coverage.
CCYYMMDD, Required.
*Use all zeros if openended.
Covered Individual’s
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
Employee or Subscriber’s
First name – Required.
10.
Effective
Date
11.
14.
Policy
Holder’s
Last Name
16
82-97
Text
Employee or Subscriber’s
Last Name – Required.
15.
Policy
Holder’s
SSN
9
98-106
Numeric
Employee or Subscriber’s
SSN – Required.
16.
Employer
Size
1
107
Numeric
Valid Values:
‘0’ = 1 to 19 employees*
‘1’ = 20 to 99 employees*
‘2’ = 100 or more employees
If no employer size is
provided, the COBC will
default this field to a value of
‘2’.
84
Section 111 GHP MSP Input File Detail Record – 425 bytes
Field
Name
Size Displacement
Data Type
Description
*Employer Size Rule for
Multi-Employer Plans: If the
employer is part of a multiemployer 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 parttime employees but is part of
a multi-employer plan where
another employer in that
group has 100 or more
employees.
Employer size must be
calculated once per calendar
year. Refer to 42 C.F.R. Part
411.101 and 42 C.F.R. Part
411.170 for details on this
calculation.
Required.
17.
Group
Policy
Number
20
108-127
Text
Policy Number Assigned by
GHP 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
Policy
Number
17
128-144
Text
Individual Policy Number;
GHP’s unique individual
identifier for the Active
Covered Individual
(beneficiary) reported on this
record. For self-insured
85
Section 111 GHP MSP Input File Detail Record – 425 bytes
Field
Name
Size Displacement
Data Type
Description
RRE’s, covered person’s
member ID or other unique
ID used to identify individuals
covered by the plan.
Required for Coverage
Types V, Z, 4, 5, and 6.
Required when submitting
a record for the Small
Employer Exception (SEE).
19.
20.
Employee
Coverage
Election
Employee
Status
1
1
145
Numeric
146
Numeric
Who the Policy Covers –
Required.
‘1’ = Policyholder/Subscriber
Only.
‘2’ = Policyholder/Subscriber
& Family.
‘3’ = Policyholder/Subscriber
& Dependents, but not
Spouse.
‘1’ = Active/Currently
Employed during GHP
effective period reported.
‘2’ = Not Active/Not Currently
Employed during GHP
effective period reported.
This value should only be
used for individuals with
ESRD.
21.
Employer
TIN
9
147-155
Numeric
Required.
Employer Tax Identification
Number (EIN) – Required.
A matching record must be
(or have been) submitted on
the TIN Reference File.
For Taft-Hartley multiple
employer/multi-employer
plans (plans using an “hours
bank” arrangement) covering
individuals who routinely
work for multiple employers
in a single Section 111
86
Section 111 GHP MSP Input File Detail Record – 425 bytes
Field
Name
Size Displacement
Data Type
Description
reporting period, submit the
plan sponsor TIN rather than
the actual employer TIN.
22.
Insurer/TPA
TIN
9
156-164
Numeric
Insurer/TPA Tax
Identification 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.
23.
National
Health Plan
10
165-174
Filler
National Health Plan
Identifier – (Future Use). Fill
with spaces.
24.
Rx Insured
ID Number
20
175-194
Text
Insured’s Identification
Number for prescription drug
coverage.
Applies to drug coverage
information reported when
using the Expanded
Reporting Option.
Required for Coverage
Types U, W, X, & Y.
25.
Rx Group
Number
15
195-209
Text
Group Number for
prescription drug coverage.
Applies to drug coverage
information reported when
using the Expanded
Reporting Option.
For use when Coverage
Type is V, Z, 4, 5, and 6.
26.
Rx PCN
10
210-219
Text
Rx Processor Control
Number.
Applies to drug coverage
information reported when
using the Expanded
Reporting Option.
87
Section 111 GHP MSP Input File Detail Record – 425 bytes
Field
27.
Name
Rx BIN
Number
Size Displacement
6
220-225
Data Type
Text
Description
Required if available.
Benefit Identification Number
for Rx processing.
Applies to drug coverage
information reported when
using the Expanded
Reporting Option.
28.
Rx Toll Free
Number
18
226- 243
Text plus
“(“ and “)”
Required for Coverage
Types U, W, X, & Y.
Prescription Drug/Pharmacy
Benefit Information Toll Free
Number.
Applies to drug coverage
information reported when
using the Expanded
Reporting Option.
29.
Person
Code
30.
Reserved
10
247-256
AlphaNumeric
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.
Reserved for COBC use.
Fill with spaces only.
31.
Reserved
5
257-261
AlphaNumeric
Reserved for COBC use.
Fill with spaces only.
32.
Small
Employer
Exception
HICN
12
262-273
AlphaNumeric
Beneficiary’s Health
Insurance Claim Number if
exception has been
approved for a small
employer.
33.
Filler
3
244-246
152
Text
274-425
AlphaNumeric
88
Fill with spaces if there is no
approval.
Unused Field.
Fill with spaces only.
Section 111 GHP MSP Input File Trailer Record – 425 bytes
Field
Name
Size Displacement
Data Type
Description
1.
Trailer
Indicator
2
1-2
AlphaNumeric
Must be: ‘T0’
2.
Section
111
Reporter
ID
9
3-11
Numeric
‘000000001’, ‘000000002’,
etc. ID number assigned by
COBC.
Required.
3.
File Type
4
12-15
Alpha
4.
File Date
8
16-23
Numeric
Date
Must be ‘MSPI’ – MSP input
file.
CCYYMMDD
Required.
5.
Record
Count
6.
Filler
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.
393
33-425
AlphaNumeric
Unused Field – fill with
spaces.
89
Section 111 GHP MSP TIN Reference File
Section 111 GHP MSP TIN Reference File Header Record – 425 bytes
Field Name
1.
2.
Size Displacement
Data Type
Description
Header
Indicator
2
1-2
AlphaNumeric
Must be: ‘H0’
Section
111
Reporter
ID
9
3-11
Numeric
‘000000001’, ‘000000002’,
etc. ID number assigned by
COBC.
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
Numeric
90
Unused Field – fill with
spaces.
Section 111 GHP MSP TIN Reference File Detail Record – 425 bytes
Field Name
1.
TIN
Size Displacement Data Type
9
1-9
Numeric
Description
Tax identification number of
the entity, or cross-reference
number to TIN field in the
detail records. Must be unique
– only one record per TIN will
be processed and saved by
the COBC. If multiple records
for the same TIN 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.
The TIN indicator field
identifies which has been
used.
2.
Name
32
10-41
Text
Required.
Name of the entity.
If the TIN on this record
reflects a plan sponsor of a
Taft-Hartley multi-employer
plan, then place the notation
“(PS)” after the name of the
plan sponsor in this field.
Required.
91
Section 111 GHP MSP TIN Reference File Detail Record – 425 bytes
Field Name
3.
Address
Line 1
Size Displacement Data Type
32
42-73
Text
Description
Address Line 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.
32
74-105
Text
Required.
Address Line 2.
5.
Address
Line 2
City
15
106-120
Text
City.
6.
State
2
121-122
Alpha
7.
Zip Code
9
123-131
AlphaNumeric
4.
8.
TIN
Indicator
1
132
Alpha
Required.
State – Must be a valid USPS
state abbreviation.
Required.
Zip Code.
First 5 positions required.
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.
Y = The TIN field contains a
“pseudo-TIN” for an employer.
Valid employer TIN/EIN is not
available.
Required.
If a “pseudo-TIN” number is
contained in the TIN field place a
92
Section 111 GHP MSP TIN Reference File Detail Record – 425 bytes
Field Name
9.
Filler
Size Displacement Data Type
293
133-425
Text
93
Description
value of ‘Y’ in this field to
indicate that the TIN field is only
to be used as a cross-reference
to the name/address fields. The
TIN field does not contain an
actual TIN. A value of ‘Y’ will not
be accepted after 1/1/2010.
Future use – Fill with
spaces.
Section 111 GHP MSP TIN Reference File Trailer Record – 425 Bytes
Field
Name
Size Displacement
Data Type
Description
1.
Trailer
Indicator
2
1-2
AlphaNumeric
Must be: ‘T0’
2.
Section
111
Reporter
ID
9
3-11
Numeric
‘000000001’, ‘000000002’,
etc. ID number assigned by
COBC.
Required.
3.
File Type
4
12-15
Alpha
4.
File Date
8
16-23
Numeric
Date
Must be: ‘REFR’ – TIN
Reference file.
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
AlphaNumeric
94
Unused Field – fill with
spaces.
Section 111 GHP MSP Response File
Section 111 GHP MSP Response File Header Record – 800 bytes
Field
Name
Size Displacement
Description
1.
Header
Indicator
2
1-2
Must be: ‘H0’
2.
Section
111
Reporter
ID
9
3-11
‘000000001’, ‘000000002’, etc. ID number
assigned by COBC.
Corresponds to the reporter ID submitted
on the MSP Input File.
3.
File Type
4
12-15
‘MSPR’ – MSP input file.
4.
File Date
8
16-23
CCYYMMDD
COBC supplied.
5.
Filler
777
24-800
Unused Field. Space filled.
Section 111 GHP MSP Response File Detail Record - 800 bytes
Field
Name
Size Displacement
Description
1.
Filler
4
1-4
For COBC internal use.
2.
HIC Number
12
5-16
Beneficiary Health Insurance Claim
Number (HICN).
Field will contain either the HICN that has
matched or the corrected HICN based on
an SSN match.
Store this HICN in your system for future
updates and deletes.
3.
Beneficiary
Surname
6
17-22
Beneficiary’s Last Name.
Field will contain either the name supplied
or the corrected name from COBC
database.
4.
Beneficiary
First Initial
1
23
Beneficiary’s First Initial.
Field will contain either the value supplied
or the corrected value from COBC
database.
5.
Beneficiary
Date of Birth
8
24-31
Beneficiary’s DOB (CCYYMMDD).
Field will contain either the value supplied
or the corrected value from COBC
database.
95
Section 111 GHP MSP Response File Detail Record - 800 bytes
Field
Name
Size Displacement
Description
6.
Beneficiary
Sex Code
1
32
Beneficiary’s Sex:
0 = Unknown
1 = Male
2 = Female
Field will contain either the value supplied
or the corrected value from COBC
database.
7.
COBC DCN
15
33-47
Document Control Number assigned by
the COBC.
COBC supplied.
8.
Disposition
Code
2
48-49
Response Disposition Code from COBC
(via the Medicare CWF).
See GHP Disposition Code Table for
values.
9.
Transaction
Type
1
50
Type of Transaction:
‘0’ = Add Record
‘1’ = Delete record
‘2’ = Update record
Transaction Type applied by COBC.
10.
Reason for
Medicare
Entitlement
1
51
Reason for Medicare Entitlement:
‘A’ = Aged
‘B’ = ESRD
‘G’ = Disabled
Value returned if individual is entitled.
COBC supplied.
96
Section 111 GHP MSP Response File Detail Record - 800 bytes
Field
Name
Size Displacement
Description
11.
Coverage
Type
(insurer
type/policy
type)
1
52
Type of Insurance:
‘J’ = Hospital Only
‘K’ = Medical Only
‘A’ = Hospital and Medical
‘U’ = Drug Only - network Rx
‘V’ = Drug with Major Medical - nonnetwork Rx
‘W’ = Comprehensive Coverage Hosp/Med/Drug - network Rx
‘X’ = Hospital and Drug - network Rx
‘Y’ = Medical and Drug - network Rx
‘Z’ = 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.
12.
Insurer
Name
32
53-84
Insurer name.
Field will contain value supplied on TIN
Reference File.
13.
Insurer
Address 1
32
85-116
Insurer’s Address Line 1.
Field will contain value supplied on TIN
Reference File.
14.
Insurer
Address 2
32
117-148
Insurer’s Address Line 2.
Field will contain value supplied on TIN
Reference File.
15.
Insurer City
15
149-163
Insurer’s City.
Field will contain value supplied on TIN
Reference File.
16.
Insurer
State
2
164-165
Insurer’s State.
Field will contain value supplied on TIN
Reference File.
17.
Insurer Zip
Code
9
166-174
Insurer’s Zip Code.
Field will contain value supplied on TIN
Reference File.
97
Section 111 GHP MSP Response File Detail Record - 800 bytes
Field
Name
Size Displacement
Description
18.
Beneficiary
SSN
9
175-183
Beneficiary’s SSN.
Field will contain either the SSN matched
or the corrected SSN based on a HICN
match.
19.
MSP
Effective
Date
8
184-191
Start date of Beneficiary’s 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 may be set to a
future date since Medicare
entitlement/enrollment information is often
established in advance.
COBC supplied.
20.
MSP
Termination
Date
8
192-199
End date of Beneficiary’s Primary GHP
Coverage (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.
COBC supplied.
21.
Relationship
Code
2
200-201
Covered Individual’s Relationship to
Active Employee:
‘01’ = Covered Individual is Active
Employee
‘02’ = Spouse or Common Law Spouse
‘03’ = Child
‘20’ = Domestic Partner
‘04’ = Other
Default is ‘01’
22.
Policy
Holder’s
First Name
9
202-210
Active Employee’s First Name.
Field will contain value supplied on input.
23.
Policy
Holder’s
Last Name
16
211-226
Active Employee’s Last Name.
Field will contain value supplied on input.
98
Section 111 GHP MSP Response File Detail Record - 800 bytes
Field
Name
Size Displacement
Description
24.
Policy
Holder’s
SSN
12
227-238
Active Employee’s SSN.
(9 digits, left justified.)
Field will contain value supplied on input.
25.
Employer’s
Name
32
239-270
Employer Providing Coverage.
Field will contain the value supplied on the
TIN Reference File.
26.
Employer’s
Address
Line 1
32
271-302
Employer’s Street Address, line 1.
Field will contain value supplied on TIN
Reference File.
27.
Employer’s
Address
Line 2
32
303-334
Employer’s Street Address, line 2.
Field will contain value supplied on TIN
Reference File.
28.
Employer’s
City
15
335-349
Employer’s City.
Field will contain value supplied on TIN
Reference File.
29.
Employer’s
State
2
350-351
Employer’s State Code.
Field will contain value supplied on TIN
Reference File.
30.
Employer’s
Zip Code
9
352-360
Employer’s Zip Code.
Field will contain value supplied on TIN
Reference File.
31.
Group
Policy
Number
20
361-380
Group Policy Number.
Field will contain value supplied on input.
32.
Individual
Policy
Number
17
381-397
Individual’s Policy Number.
Field will contain value supplied on input.
33.
Last Query
Date
8
398-405
Last Date Sent to Medicare CWF
(Common Working File) (CCYYMMDD).
COBC supplied.
34.
Current
Disposition
Code
2
406-407
Result from Most Current CWF
Transmission (same as Field #8).
COBC supplied.
35.
Current
Disposition
Date
8
408-415
Date of Most Current CWF Transmission
(CCYYMMDD).
COBC supplied.
99
Section 111 GHP MSP Response File Detail Record - 800 bytes
Field
Name
Size Displacement
Description
36.
Previous
Disposition
Code
2
416-417
Result from Previous CWF Transmission.
COBC supplied.
37.
Previous
Disposition
Date
8
418-425
Date of Previous CWF Transmission
(CCYYMMDD).
COBC supplied.
38.
First
Disposition
Code
2
426-427
Result from First CWF Transmission.
COBC supplied.
39.
First
Disposition
Date
8
428-435
Date of First CWF Transmission
(CCYYMMDD).
COBC supplied.
40.
Error Code
1
4
436-439
SP Error Code 1
See SP Error Code Table for values.
COBC or CWF supplied.
41.
Error Code
2
4
440-443
SP Error Code 2
See SP Error Code Table for values.
COBC or CWF supplied.
42.
Error Code
3
4
444-447
SP Error Code 3
See SP Error Code Table for values.
COBC or CWF supplied.
43.
Error Code
4
4
448-451
SP Error Code 4
See SP Error Code Table for values.
COBC or CWF supplied.
44.
Split
Entitlement
Indicator
1
452
Entitlement Split Indicator:
‘Y’ = yes
‘N’ or blank = no
COBC supplied.
45.
Original
Reason for
Medicare
Entitlement
1
453
Original Reason for Medicare Entitlement:
‘A’ = Aged
‘B’ = ESRD
‘G’ = Disabled
COBC supplied.
100
Section 111 GHP MSP Response File Detail Record - 800 bytes
Field
Name
Size Displacement
Description
46.
Original
Coverage
Effective
Date
8
454-461
The original GHP coverage effective date
sent. This gets populated if a SP31 error
occurs (CCYYMMDD).
Field will be the value supplied on input.
47.
Original
Coverage
Termination
Date*
8
462-469
The original GHP coverage termination
date sent. This gets populated if a SP32
error occurs (CCYYMMDD).
Field will be the value supplied on input.
*All zeros if open-ended.
48.
RRE
Assigned
DCN
15
470-484
The Document Control Number assigned
by the Section 111 GHP responsible
reporting entity. It is moved here so we
can provide our own unique COBC DCN
in Field 7.
Field will be the value supplied on input.
49.
Current
Medicare
Part A
Effective
Date
8
485-492
Effective Date of Medicare Part A
Coverage (CCYYMMDD).
COBC supplied.
50.
Current
Medicare
Part A
Termination
Date*
8
493-500
Termination Date of Medicare Part A
Coverage (CCYYMMDD).
COBC supplied.
* All zeros if open-ended.
51.
Current
Medicare
Part B
Effective
Date
8
501-508
Effective Date of Medicare Part B
Coverage (CCYYMMDD).
52.
Current
Medicare
Part B
Termination
Date*
8
509-516
Termination Date of Medicare Part B
Coverage (CCYYMMDD).
COBC supplied.
* All zeros if open-ended.
53.
Medicare
Beneficiary
Date of
Death
8
517-524
Medicare Beneficiary Date of Death
(CCYYMMDD).
COBC supplied.
COBC supplied.
101
Section 111 GHP MSP Response File Detail Record - 800 bytes
Field
Name
Size Displacement
54.
Current
Medicare
Part C Plan
Contractor
Number
5
525-529
Contractor Number of the current
Medicare Part C Plan in which the
beneficiary is enrolled.
COBC supplied.
55.
Current
Medicare
Part C Plan
Enrollment
Date
8
530-537
Effective Date of coverage provided by
current Medicare Part C Plan
(CCYYMMDD).
COBC supplied.
56.
Current
Medicare
Part C Plan
Termination
Date*
8
538-545
Termination Date of coverage provided by
current Medicare Part C Plan
(CCYYMMDD).
COBC supplied.
* All zeros if open-ended (i.e., if coverage
is not terminated).
57.
Current
Medicare
Part D Plan
Contractor
Number
5
546-550
Contractor Number of the current
Medicare Part D Plan in which the
beneficiary is enrolled.
COBC supplied.
Only provided to Expanded Reporting
Option Section 111 reporters.
58.
Current Part
D Plan
Enrollment
Date
8
551-558
Effective Date of coverage provided by
current Medicare Part D Plan
(CCYYMMDD).
COBC supplied.
Only provided to Expanded Reporting
Option Section 111 reporters.
59.
Current
Medicare
Part D Plan
Termination
Date*
8
559-566
Termination Date of coverage provided by
current Medicare Part D Plan
(CCYYMMDD).
COBC supplied.
* All zeros if open-ended (i.e., if coverage
is not terminated).
Only provided to Expanded Reporting
Option Section 111 reporters.
102
Description
Section 111 GHP MSP Response File Detail Record - 800 bytes
Field
Name
Size Displacement
Description
60.
Part D
Eligibility
Start Date
8
567-574
Earliest date that Beneficiary is eligible to
receive Part D Benefits – Refer to Field 58
for Part D Plan Enrollment Date
(CCYYMMDD).
COBC supplied.
Only provided to Expanded Reporting
Option Section 111 reporters.
61.
Part D
Eligibility
Stop Date*
8
575-582
Date the Beneficiary is no longer eligible
to receive Part D Benefits – Refer to Field
59 for Part D Plan Termination Date
(CCYYMMDD).
COBC supplied.
* All zeros if open-ended.
Only provided to Expanded Reporting
Option Section 111 reporters.
62.
National
Health Plan
ID
10
583-592
National Health Plan Identifier. (Future
requirement.)
Field will contain value supplied on input.
63.
Rx Insured
ID number
20
593-612
Insured’s Identification Number.
Field will contain value supplied on input.
64.
Rx Group
Number
15
613-627
Group Number.
Field will contain value supplied on input.
65.
Rx PCN
10
628-637
Processor Control Number.
Field will contain value supplied on input.
66.
Rx BIN
Number
6
638-643
Benefit Identification Number for Rx
processing.
Field will contain value supplied on input.
67.
Rx 800
Number
18
644-661
Pharmacy benefit information Toll Free
Number.
Field will contain value supplied on input.
68.
Person
Code
3
662-664
Person Code.
Field will contain value supplied on input.
69.
Rx
Disposition
Code
2
665-666
Response Rx Disposition Code from
COBC (Medicare Beneficiary Database or
MBD).
See GHP Disposition Code Table for
values.
Code supplied by the COBC.
103
Section 111 GHP MSP Response File Detail Record - 800 bytes
Field
Name
Size Displacement
Description
70.
Rx
Disposition
Date
8
667-674
Date Rx Disposition Code was generated
(CCYYMMDD).
Code supplied by the COBC.
71.
Rx Error
Code 1
4
675-678
Rx Error Code 1.
Refer to GHP Rx Error Codes for values.
COBC supplied.
72.
Rx Error
Code 2
4
679-682
Rx Error Code 2.
Refer to GHP Rx Error Codes for values.
COBC supplied.
73.
Rx Error
Code 3
4
683-686
Rx Error Code 3.
Refer to GHP Rx Error Codes for values.
COBC supplied.
74.
Rx Error
Code 4
4
687-690
Rx Error Code 4.
Refer to GHP Rx Error Codes for values.
COBC supplied.
75.
ESRD
Coordination
Period Start
Date
8
691-698
The start date for the 30-month
coordination period in which GHP
coverage is considered primary to
Medicare because the beneficiary has a
diagnosis of End Stage Renal Disease
(CCYYMMDD).
COBC supplied.
76.
ESRD
Coordination
Period End
Date
8
699-706
The ending date for the 30-month
coordination period in which GHP
coverage is 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).
COBC supplied.
77.
First Dialysis
Date
8
707-714
A date that indicates when the ESRD
Dialysis first started (CCYYMMDD).
Value will be zero if not applicable.
COBC supplied.
104
Section 111 GHP MSP Response File Detail Record - 800 bytes
Field
Name
Size Displacement
78.
ESRD SelfTraining
Date
8
715-722
A date that indicates when the beneficiary
participated in ESRD Self - Care Training
(CCYYMMDD).
Value will be zero if not applicable.
COBC supplied.
79.
Transplant
Date – Most
Recent
8
723-730
A date that indicates when a Kidney
Transplant Operation occurred
(CCYYMMDD).
Value will be zero if not applicable.
COBC supplied.
80.
Transplant
Failure Date
– Most
Recent
8
731-738
A date that indicates when a Kidney
Transplant failed. Last occurrence will be
reported (CCYYMMDD).
COBC supplied.
81.
SEE
Response
Code
2
739-740
Small Employer Exception (SEE)
Response Code.
(Spaces): Not applicable. SEE HICN not
provided
SA – SEE HICN accepted
SN – SEE HICN not accepted
SP – SEE HICN partially accepted (SEE
HICN period does not cover entire MSP
period)
COBC supplied.
82.
Late
Submission
Indicator
1
741-741
Indicates that the submitted record was
not received on schedule. The GHP
effective date was more than 45 calendar
days older than the start date of the
scheduled Section 111 submission.
COBC supplied.
83.
Compliance
Flag 1
2
742-743
Alphanumeric code indicating compliance
issue found with record.
See Compliance Code Table for values.
COBC supplied.
84.
Compliance
Flag 2
2
744-745
Alphanumeric code indicating compliance
issue found with record.
See Compliance Code Table for values.
Used when more than one issue found.
COBC supplied.
105
Description
Section 111 GHP MSP Response File Detail Record - 800 bytes
Field
Name
Size Displacement
85.
Compliance
Flag 3
2
746-747
Alphanumeric code indicating compliance
issue found with record.
See Compliance Code Table for values.
Used when more than two issues found.
COBC supplied.
86.
Compliance
Flag 4
2
748-749
Alphanumeric code indicating compliance
issue found with record.
See Compliance Code Table for values.
Used when more than three issues found.
COBC supplied.
87.
Compliance
Flag 5
2
750-751
Alphanumeric code indicating compliance
issue found with record.
See Compliance Code Table for values.
Used when more than four issues found.
COBC supplied.
88.
Compliance
Flag 6
2
752-753
Alphanumeric code indicating compliance
issue found with record.
See Compliance Code Table for values.
Used when more than five issues found.
COBC supplied.
89.
Compliance
Flag 7
2
754-755
Alphanumeric code indicating compliance
issue found with record.
See Compliance Code Table for values.
Used when more than six issues found.
COBC supplied.
90.
Compliance
Flag 8
2
756-757
Alphanumeric code indicating compliance
issue found with record.
See Compliance Code Table for values.
Used when more than seven issues
found.
COBC supplied.
91.
Compliance
Flag 9
2
758-759
Alphanumeric code indicating compliance
issue found with record.
See Compliance Code Table for values.
Used when more than eight issues found.
COBC supplied.
106
Description
Section 111 GHP MSP Response File Detail Record - 800 bytes
Field
Name
Size Displacement
92.
Compliance
Flag 10
2
760-761
Alphanumeric code indicating compliance
issue found with record.
See Compliance Code Table for values.
Used when more than nine issues found.
COBC supplied.
93.
Filler
39
762-800
Unused field. Space filled.
107
Description
Appendix B – Query Only HEW Input/Output 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 COBC to process the X12 270/271. If you are using your own ANSI X12
translator, please contact your assigned COBC EDI Representative for the necessary
mapping documentation.
Section 111 Query Only Input File Header Record – 38 Bytes
Field
Name
Size
1.
Header Indicator
2
Displac
ement
1-2
Description
2.
VDSA ID
4
3-6
3.
Contractor Number
5
7-11
4.
5.
File Type
Cycle Date
4
8
12-15
16-23
‘0001’, ‘0002’, etc. ID number
assigned by COBC (previously
known as “Plan Number”).
‘11106’ - Insurer
‘11105’ – Employer
‘11112’ – BCBS
‘IACT’ – Inactive.
File date (CCYYMMDD).
6.
Filler
15
24-38
Unused Field.
Must be: ‘H0’
Section 111 Query Only Input File Detail Record – 38 Bytes
Field Name
1.
HIC Number
2.
3.
4.
Last Name
First Initial
DOB
5.
Sex Code
6.
SSN
7.
Filler
Size Displacement Description
12
1-12
Medicare Health Insurance Claim
Number (if available).
6
13-18
Surname of Covered Individual.
1
19-19
First Initial of Covered Individual.
8
20-27
Covered Individual's Date of Birth
(CCYYMMDD).
1
28-28
Covered Individual's Gender:
0 = Unknown
1 = Male
2 = Female
9
29-37
Social Security Number of the
Covered Individual.
1
38
Filler.
108
Section 111 Query Only Input File Trailer Record – 38 Bytes
Field Name
Size Displacement Description
1.
Trailer Indicator
2
1-2
Must be: ‘T0’
2.
VDSA ID
4
3-6
3.
Contractor Number
5
7-11
4.
5.
File Type
Cycle Date
4
8
12-15
16-23
‘0001’, ‘0002’, etc. ID
number assigned by COBC
(previously known as “Plan
Number”).
‘11106’ – Insurer
‘11105’ – Employer
‘11112’ – BCBS
‘IACT’ – Inactive.
File date (CCYYMMDD).
6.
Record Count
9
24-32
7.
Filler
6
33-38
Number of individual query
records in this file. Do not
include the Header and
Trailer Records in the
Record Count.
Unused Field.
Note: The Query Only Response File does not have a header or trailer record.
Section 111 Query Only Response File Record – 116 Bytes
Field Name
1.
HIC Number
2.
Surname
3.
First Initial
4.
DOB
5.
Sex Code
6.
SSN
7.
Entitlement Reason
(Medicare reason)
Size Displacement Description
12
1-12
Medicare Health Insurance
Claim Number.
6
13-18
Surname of Covered
Individual.
1
19-19
First Initial of Covered
Individual.
8
20-27
Covered Individual's Date
of Birth (CCYYMMDD).
1
28-28
Covered Individual's
Gender:
0 = Unknown
1 = Male
2 = Female
9
29-37
Social Security Number of
the Covered Individual.
1
38
Reason for Medicare
Entitlement:
A = Aged
B = ESRD
G = Disabled
109
Section 111 Query Only Response File Record – 116 Bytes
Field Name
8.
Current Medicare Part A
Effective Date
9.
Current Medicare Part A
Termination Date*
10.
Current Medicare Part B
Effective Date
11.
Current Medicare Part B
Termination Date*
12.
Medicare Beneficiary Date
of Death
Current Medicare Part C
Plan Contractor Number
13.
14.
Current Medicare Part C
Plan Enrollment Date
15.
Current Medicare Part C
Plan Termination Date*
16.
Disposition Code
17.
CMS Document Control
Number
Size Displacement Description
8
39-46
Effective Date of Medicare
Part A Coverage
(CCYYMMDD).
8
47-54
Termination Date of
Medicare Part A Coverage
(CCYYMMDD).
* Blank if ongoing.
8
55-62
Effective Date of Medicare
Part B Coverage
(CCYYMMDD).
8
63-70
Termination Date of
Medicare Part B Coverage
(CCYYMMDD).
*Blank if ongoing.
8
71-78
Beneficiary Date of Death
(CCYYMMDD).
5
79-83
Contractor Number of the
current Part C Plan in which
the beneficiary is enrolled.
COBC supplied value.
8
84-91
Effective Date of coverage
provided by the
beneficiary’s current
Medicare Part C Plan
(CCYYMMDD).
8
92-99
Termination Date of the
coverage provided by the
beneficiary’s current
Medicare Part C Plan
(CCYYMMDD).
*Blank if ongoing.
2
100-101
01 = Record Accepted.
Individual was found to be a
Medicare Beneficiary.
51 = Individual was not
found to be a Medicare
beneficiary.
15
102-116
VDSA ID (102-105),
Julian Date (106-110),
Sequence Counter (111116).
110
Appendix C – Non-MSP File Specifications
Section 111 GHP Non-MSP Input File – Expanded
Reporting Option Only
Section 111 GHP Non-MSP Input File Header Record – 300 bytes
Field Name
Size
Displacement
Data type
Description
1.
Header
Indicator
2
1-2
AlphaNumeric
Must be: ‘H0’
2.
Section 111
Reporter ID
9
3-11
Numeric
‘000000001’, ‘000000002’, etc.
ID number assigned by COBC.
Required.
3.
File Type
4
12-15
Alpha
4.
File Date
8
16-23
Numeric
CCYYMMDD
Required.
5.
RDS
Application
Number
10
24-33
AlphaNumeric
Retiree Drug Subsidy ID
number that is associated with a
particular 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. Fill with
spaces for Action Types D
and N.
6.
Filler
267
34-300
Filler
111
Must be: ‘NMSI’ – non-MSP
input file.
Unused Field.
Section 111 GHP Non-MSP Input File Detail Record – 300 bytes
Field
Name
1. Beneficiary
Social
Security
Number
2. HIC Number
(HICN)
Size Displacement
9
12
1-9
Data
type
Numeric
10-21
AlphaNumeric
Description
Inactive Covered Individual’s
Social Security Number.
Required if HICN field
(below) not populated.
Fill with spaces if SSN is not
available.
Inactive Covered Individual’s
Health Insurance Claim
Number (Medicare ID
number). Required if SSN
field (above) not populated.
Populate with spaces if not
available.
Inactive Covered Individual’s
Last Name – Required.
3. Covered
Individual’s
Surname
4. Covered
Individual’s
First Initial
5. Covered
Individual’s
Middle Initial
6. Covered
Individual’s
Date of Birth
6
22-27
Text
1
28-28
Alpha
Inactive Covered Individual’s
First Initial – Required.
1
29-29
Alpha
Inactive Covered Individual’s
Middle Initial – Optional.
8
30-37
Numeric
Date
Inactive Covered Individual’s
DOB (CCYYMMDD).
Required.
7. Covered
Individual’s
Sex Code
1
38-38
Numeric
Inactive Covered Individual’s
Sex –
Valid values:
0 = Unknown
1 = Male
2 = Female
Required.
112
Section 111 GHP Non-MSP Input File Detail Record – 300 bytes
Field
Name
Size Displacement
Data
type
Description
8. Group
Health Plan
(GHP)
Number
20
39-58
Text
GHP Number assigned by
Payer for Action Type D, or,
Unique Benefit Option
Identifier assigned by Payer
for Action Type S. 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
Policy
Number
17
59-75
Text
Unique Identifier assigned by
the payer to identify the
covered 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
Date
8
76-83
Numeric
Date
Start Date of Covered
Individual’s GHP Coverage by
Insurer (CCYYMMDD).
Required for Action Types
D and S.
11. Termination
Date**
8
84-91
Numeric
Date
End Date of Covered
Individual’s 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
Health Plan
10
92-101
Filler
National Health Plan
Identifier. (Future Use.)
13. Rx Insured
ID Number
20
102-121
Text
Insured’s Rx Identification
Number.
For use with Action Types D
and S.
Required for Action Type D
when Coverage Type = U,
W, X, or Y.
113
Section 111 GHP Non-MSP Input File Detail Record – 300 bytes
Field
Name
Size Displacement
Data
type
Description
14. Rx Group
Number
15
122-136
Text
Rx Group Health Plan
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.
Required with Action Type
S when Coverage Type = U,
W, X, or Y.
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.
16. Rx BIN
Number
6
147-152
Text
Benefit Identification Number
for 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.
17. Rx Toll Free
Number
18
153-170
Text plus
“(“ and “)”
Toll Free Number Pharmacist
can use to contact Rx Insurer.
For use with Action Types D
and S.
18. Relationship
Code
2
171-172
Numeric
Covered Individual’s Relation
to 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
114
Section 111 GHP Non-MSP Input File Detail Record – 300 bytes
Field
Name
Size Displacement
Data
type
Description
D and S.
19. DCN
15
173-187
Text
20. Action Type
1
188
Alpha
21 Transaction
Type
1
189
AlphaNumeric
22. Coverage
Type
1
190
AlphaNumeric
115
Document Control Number;
assigned by the Section 111
GHP RRE.
Required. Each record
within the current file must
have a unique DCN.
Type of Record:
Valid values:
‘D’ = Drug Reporting record
‘S’ = Subsidy Reporting
record
‘N’ = Non-Reporting record
Required.
Type of Transaction:
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.
Type of Coverage:
‘U’ - Drug Only - network Rx
‘V’ - Drug with Major Medical 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
Account - non-network Rx
‘4’ = Comprehensive
Coverage - Hosp/Med/Drug non-network Rx
‘5’ = Hospital and Drug - non-
Section 111 GHP Non-MSP Input File Detail Record – 300 bytes
Field
Name
Size Displacement
Data
type
Description
network Rx
‘6’ = Medical and Drug - nonnetwork Rx
Required for Action Types
D or S.
23. Person
Code
3
191-193
Text
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 COBC internal
use;
Fill with spaces only.
26. Reserved
1
209
Internal
use
Reserved for COBC 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.
28. Filler
59
242-300
Filler
Unused field.
116
Person Code the plan uses to
identify specific individuals on
a policy.
For use with Action Types D
and S.
Section 111 GHP Non-MSP Input File Trailer Record – 300 bytes
Field
Name
Size
Displacement
Data type
Description
1.
Trailer
Indicator
2
1-2
AlphaNumeric
Must be: ‘T0’
2.
Section
111
Reporter
ID
9
3-11
Numeric
‘000000001’, ‘000000002’, etc.
ID number assigned by COBC.
Required.
3.
File Type
4
12-15
Alpha
4.
File Date
8
16-23
Numeric
CCYYMMDD
Required.
5.
S Record
Count
9
24-32
Numeric
Number of Action Type ‘S’
records on file.
Required.
6.
D Record
Count
9
33-41
Numeric
Number of Action Type ‘D’
records on file.
Required.
7.
N Record
Count
9
42-50
Numeric
Number of Action Type ‘N’
records on file.
Required.
8.
Total
Record
Count
9
51-59
Numeric
Number of detail records in this
file. Do not include the
Header and Trailer Records in
the Record Count.
Required.
9.
Filler
241
60-300
Filler
117
Must be: ‘NMSI’ – non-MSP
input file.
Unused Field.
Section 111 GHP Non-MSP Response File
Section 111 GHP Non-MSP Response File Header Record – 500 bytes
Field Name
Size
Displacement Description
1.
Header
Indicator
2
1-2
Must be: ‘H0’
2.
Section 111
Reporter ID
9
3-11
‘000000001’, ‘000000002’, etc. ID number
assigned by COBC.
Corresponds to the Reporter 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
Application
Number
10
24-33
Retiree Drug Subsidy ID number assigned
by the RDS contractor that is associated
with a particular 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.
118
Section 111 GHP Non-MSP Response File Detail Record - 500 bytes
Field
Name
Size Displacement
Description
1.
Filler
4
1-4
COBC use.
2.
SSN
9
5-13
Beneficiary’s SSN.
Included for Action Types D, S, and N.
Field will contain either the SSN
matched, or a corrected SSN based on
a HICN match.
3.
HIC Number
12
14-25
Beneficiary’s Medicare Health Insurance
Claim Number (HICN).
Included for Action Types D, S, and N.
Field will contain either the HICN
matched, or a corrected HICN based on
a SSN match.
Store this HICN in your system for future
updates and deletes.
4.
Covered
Individual’s
Surname
6
26-31
Beneficiary’s Last Name.
Included for Action Types D, S, and N.
Field will contain either the name
supplied or a corrected name from
COBC database.
5.
Beneficiary
First Initial
1
32
Beneficiary’s First Initial.
Included for Action Types D, S, and N.
Field will contain either the value
supplied or a corrected value from
COBC database.
6.
Beneficiary
Middle Initial
1
33
Beneficiary’s Middle Initial.
Included for Action Types D, S, and N.
Field will contain the value supplied.
7.
Beneficiary
Date of Birth
8
34-41
Beneficiary’s DOB (CCYYMMDD).
Included for Action Types D, S, and N.
Field will contain either the value
supplied or a corrected value from
COBC database.
119
Section 111 GHP Non-MSP Response File Detail Record - 500 bytes
Field
Name
Size Displacement
Description
8.
Beneficiary
Sex Code
1
42
Beneficiary’s Sex:
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.
9.
Group Health
Plan Number
20
43-62
GHP 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.
Included for Action Types D and S.
Field will contain the value supplied on
input.
10.
Individual
Policy
Number
17
63-79
Policy 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 nonapplicable.
Included for Action Types D and S.
Field will contain the term date applied to
the supplemental drug coverage record.
13.
National
Health Plan
ID
10
96-105
National Health Plan Identifier. For
Action Types D and S. (Future Use).
120
Section 111 GHP Non-MSP Response File Detail Record - 500 bytes
Field
Name
Size Displacement
14.
Rx Insured ID
Number
20
106-125
Insured’s Rx Identification Number.
Included for Action Types D and S.
Field will contain the value supplied on
input.
15.
Rx Group
Number
15
126-140
Rx Group Health Plan Number assigned
by payer for 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
Number
18
157-174
Pharmacy benefit Toll Free 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.
121
Description
Section 111 GHP Non-MSP Response File Detail Record - 500 bytes
Field
Name
Size Displacement
Description
20.
Relationship
Code
2
178-179
Beneficiary’s Relationship to active
employee:
‘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
DCN
15
180-194
The Document Control Number assigned
by the Section 111 GHP RRE. Included
for Action Types D, S, and N.
Field will contain the value supplied on
input.
22.
COBC DCN
15
195-209
COBC Document Control Number.
Included for Action Types D, S, and N.
Field will contain the DCN created for
this record by the COBC.
23.
Original
Action Type
1
210
Type of Record:
‘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 COBC
(COBC 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.
COBC supplied value.
122
Section 111 GHP Non-MSP Response File Detail Record - 500 bytes
Field
Name
Size Displacement
Description
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.
26.
Coverage
Type
1
213
Type of Coverage:
‘U’ = Drug Only - network Rx
‘V’ = Drug with Major Medical - nonnetwork Rx
‘W’ = Comprehensive Coverage Hosp/Med/Drug - network Rx
‘X’ = Hospital and Drug - network Rx
‘Y’ = Medical and Drug - network Rx
‘Z’ = 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
Included for Action Types D and S.
Field will contain the value supplied on
input.
27.
Filler
1
214
Unused Field.
28.
Reason for
Medicare
Entitlement
1
215
Reason for Medicare Entitlement:
‘A’ = Aged
‘B’ = ESRD
‘G’ = Disabled
Included for Action Types D and N.
COBC-supplied value.
123
Section 111 GHP Non-MSP Response File Detail Record - 500 bytes
Field
Name
Size Displacement
29.
S Disposition
Code
2
216-217
Cross-walked result from RDS
processing to COBC disposition codes.
Included for records submitted with ‘S’
Action Type.
RDS-supplied value converted to Section
111 GHP specific S Disposition Code.
Refer to Field 53 (RDS Reason Code)
and Field 54 (RDS Determination
Indicator) for actual codes supplied by
the RDS Center.
30.
S Disposition
Date
8
218-225
Date S Disposition determined
(CCYYMMDD).
Included for records with an original S
Action Type.
RDS Center supplied value.
31.
Current
Medicare Part
A Effective
Date
8
226-233
Effective Date of Medicare Part A
Coverage (CCYYMMDD).
Included for all Action Types.
COBC supplied value.
32.
Current
Medicare Part
A Termination
Date*
8
234-241
Termination Date of Medicare Part A
Coverage (CCYYMMDD).
Included for all Action Types.
COBC supplied value.
* All zeros if open-ended or not
applicable.
33.
Current
Medicare Part
B Effective
Date
8
242-249
Effective Date of Medicare Part B
Coverage (CCYYMMDD).
Included for all Action Types.
COBC supplied value.
34.
Current
Medicare Part
B Termination
Date*
8
250-257
Termination Date of Medicare Part B
Coverage (CCYYMMDD).
Included for all Action Types.
COBC supplied value.
* All zeros if open-ended or not
applicable.
124
Description
Section 111 GHP Non-MSP Response File Detail Record - 500 bytes
Field
Name
Size Displacement
Description
35.
Part D
Eligibility
Start Date
8
258-265
Earliest date that beneficiary is eligible to
enroll in Part D – Refer to Field 42 for the
Part D Plan Enrollment Date
(CCYYMMDD).
Included for all Action Types.
COBC supplied value.
36.
Part D
Eligibility Stop
Date*
8
266-273
Date the beneficiary is no longer eligible
to receive Part D Benefits – Refer to
Field 43 for the Part D Plan Termination
Date (CCYYMMDD).
Included for all Action Types.
COBC supplied value.
* All zeros if open-ended or not
applicable.
37.
Medicare
Beneficiary
Date of
Death*
8
274-281
Medicare Beneficiary Date of Death
(CCYYMMDD).
Included for all Action Types.
COBC supplied value.
* All zeros if not applicable.
38.
Current
Medicare Part
C Plan
Contractor
Number
5
282-286
Contractor Number of the current Part C
Plan in which the beneficiary is enrolled.
Included for all Action Types.
COBC supplied value.
39.
Current
Medicare Part
C Plan
Enrollment
Date
8
287-294
Effective Date of coverage provided by
the Beneficiary’s current Medicare Part C
Plan (CCYYMMDD).
Included for all Action Types.
COBC supplied value.
40.
Current
Medicare Part
C Plan
Termination
Date*
8
295-302
Termination Date of the coverage
provided by the Beneficiary’s current
Medicare Part C Plan (CCYYMMDD).
Included for all Action Types.
COBC supplied value.
* All zeros if open-ended or not
applicable.
125
Section 111 GHP Non-MSP Response File Detail Record - 500 bytes
Field
Name
41.
Current
Medicare Part
D Plan
Contractor
Number
5
303-307
42.
Current
Medicare Part
D Plan
Enrollment
Date
Current
Medicare Part
D Plan
Termination
Date*
8
308-315
8
316-323
44.
Error Code 1
4
324-327
45.
Error Code 2
4
328-331
46.
Error Code 3
4
332-335
43.
Size Displacement
Description
Contractor Number of the current
Medicare Part D Plan in which the
Beneficiary is enrolled.
Included for all Action Types.
COBC supplied value.
Effective Date of coverage provided by
the Current Medicare Part D Plan
(CCYYMMDD).
Included for all Action Types.
COBC supplied value.
Termination Date of coverage provided
by the current Medicare Part D Plan
(CCYYMMDD).
Included for all Action Types.
COBC supplied value.
* All zeros if open-ended or not
applicable.
Error Code 1 – May contain SP or RX
error codes from COBC or RDS
processing if applicable.
See SP and Rx Error Code Tables for
values.
COBC supplied value for D/N records.
RDS supplied value for S records.
Error Code 2 – May contain SP or RX
error codes from COBC or RDS
processing if applicable.
See SP and Rx Error Code Tables for
values.
COBC supplied value for D/N records.
RDS supplied value for S records.
Error Code 3 – May contain SP or RX
error codes from COBC or RDS
processing if applicable.
See SP and Rx Error Code Tables for
values.
COBC supplied value for D/N records.
RDS supplied value for S records.
126
Section 111 GHP Non-MSP Response File Detail Record - 500 bytes
Field
Name
47.
Error Code 4
4
336-339
48.
D/N
Disposition
Code
2
340-341
49.
D/N
Disposition
Date
RDS Start
Date
8
342-349
8
350-357
51.
RDS End
Date
8
358-365
52.
RDS Split
Indicator
1
366
50.
Size Displacement
Description
Error Code 4 – May contain SP or RX
error codes from COBC or RDS
processing if applicable.
See SP and Rx Error Code Tables for
values.
COBC supplied value for D/N records.
RDS supplied value for S records.
Result from processing of an Action
Type D or N record. This will also be
used to provide a disposition for D
records converted from S records – in
such case, the S Disposition (Field 30)
will also be populated.
See GHP Disposition Code Table for
values.
Code supplied by the COBC.
Processing date associated with the D/N
Disposition Code (CCYYMMDD).
Supplied by the COBC.
Start date for the RDS subsidy period
(CCYYMMDD).
RDS-supplied value.
End date for RDS subsidy period
(CCYYMMDD).
RDS-supplied value.
Indicates multiple subsidy periods within
the plan year. Expect multiple records.
Values:
‘Y’ if applicable.
Space if not applicable.
RDS-supplied value.
127
Section 111 GHP Non-MSP Response File Detail Record - 500 bytes
Field
Name
Size Displacement
53.
RDS Reason
Code*
2
367-368
54.
RDS
Determination
Indicator
1
369
55.
ESRD
Coverage
Period
Effective Date
8
370-377
Description
Spaces = Accepted
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
10= Enrolled in Part D
11= Not eligible for Medicare
12= Beneficiary is deceased
13= Invalid HICN 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.
Y = Yes, the retiree qualifies for the RDS
subsidy.
N = No, the retiree does not qualify for
the RDS subsidy.
This indicator may be blank on records in
unsolicited RDS response files.
RDS supplied value.
The date on which the beneficiary is
entitled to Medicare in some part
because of a diagnosis of End Stage
Renal Disease (CCYYMMDD). Last
coverage period will be reported if
multiple coverage periods exist.
Supplied by the COBC.
128
Section 111 GHP Non-MSP Response File Detail Record - 500 bytes
Field
Name
Size Displacement
Description
56.
ESRD
Coverage
Period Term
Date
8
378-385
The date on which the beneficiary is no
longer entitled to Medicare under ESRD
Provisions (CCYYMMDD). Last
coverage period will be reported if
multiple coverage periods exist.
Supplied by the COBC.
57.
First Dialysis
Date
8
386-393
A date that indicates when the
beneficiary first started ESRD Dialysis
(CCYYMMDD).
Supplied by the COBC.
58.
ESRD SelfTraining Date
8
394-401
A date that indicates when the
beneficiary participated in ESRD Self
Care Training (CCYYMMDD).
Supplied by the COBC.
59.
Transplant
Date – Most
Recent
8
402-409
A date that indicates when a Kidney
Transplant Operation Occurred
(CCYYMMDD). Last occurrence will be
reported.
Supplied by the COBC.
60.
Transplant
Failure Date
– Most
Recent
8
410-417
61.
Filler
83
418-500
A date that indicates when a Kidney
Transplant failed (CCYYMMDD). Last
occurrence will be reported.
Supplied by the COBC.
Unused Field. Filled with spaces.
129
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
Reporter ID
9
3-11
‘000000001’, ‘000000002’, etc. ID
number assigned by COBC.
Corresponds to the Reporter 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.
COBC Supplied.
6.
Filler
468
33-500
Unused Field. Space filled.
130
Appendix D – Disposition, Error and Compliance Codes
Section 111 GHP Disposition Codes
Disposition Description
Codes
01
SP
50
51
52
53
55
61
AB
CI
Record accepted by the Medicare Common Working File (CWF) or
the Medicare Beneficiary Database (MBD) as an “Add” or an
“Update” record. An MSP occurrence or supplemental drug record
was added, updated or deleted. For queries, the individual was
found to be a Medicare beneficiary and the response record
contains Medicare entitlement and enrollment information.
Transaction edit; record returned with at least one SP or RX edit
(specific SP and RX edits are described below). Record must be
corrected and resubmitted on the next file submission.
Record still being processed by CMS. Internal CMS use only;
resubmit record on next file submission.
Individual was not found to be a Medicare Beneficiary. Record will
not be recycled. Individual is most likely not entitled to Medicare.
RRE should verify individual’ status based on information in its files
and resubmit record on next file submission.
RREs will receive this disposition code if neither the HICN nor SSN
is submitted on the input record. In this case the RRE must obtain a
valid HICN or SSN and resubmit the record on the next file
submission.
Record still being processed by CMS. Internal CMS use only;
resubmit record on next file submission.
Record in alpha match at CMS. Internal CMS use only; resubmit
record on next file submission.
Name/Personal Characteristic Mismatch. Name or personal
characteristic of beneficiary does not match the Health Insurance
Claim Number (HICN) on Medicare's files. RRE needs to verify
name, HICN, date of birth and gender based on information in its
files; resubmit record on next file submission.
Cross-Reference Data Base Problem. Internal CMS use only;
resubmit record on next file submission.
CWF problem that can only be resolved by CWF Technician.
Internal CMS use only; resubmit record on next file submission.
Processing Error. Internal CMS use only; resubmit record on next
file submission.
131
Disposition Description
Codes
ID
BY
Drug Record Processing Error. Internal CMS use only; resubmit
record on next file submission.
Bypass. Record was bypassed. SEE HICN was submitted by RRE
and accepted; resubmit record on next file submission.
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). Resubmit record on next file
submission as the beneficiary’s reason for Medicare entitlement is
subject to change.
132
Section 111 GHP SP Error Codes
SP
DESCRIPTION
ERROR
CODE
SP 11 Invalid MSP Transaction Record Type. No
correction necessary - resubmit records
with this error on your next file submission.
SP 12 Invalid HICN (Mandatory). Field must contain
alpha and numeric characters. You received
this error because an invalid character was
found in this field.
SP 13 Invalid Beneficiary/Individual Surname
(Mandatory). Field must contain alpha
characters. Field cannot be blank or contain
spaces or numeric characters.
SP 14 Invalid Beneficiary/Individual First Name Initial
(Mandatory). Field must contain alpha
character. Field cannot be blank or contain
spaces, numeric characters, or punctuation
marks.
SP 15 Invalid Beneficiary/Individual Date of Birth
(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 date = 30, the record will reject.
SP 16 Invalid Beneficiary/Individual Sex Code
(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
SP 17 Invalid Contractor Number (Mandatory). No
correction necessary - resubmit records
with this error on your next file submission.
SP 18 Invalid Document Control Number (DCN)
submitted by COBC to CWF. No correction
necessary - resubmit records with this
error on your next file submission.
133
COBC
RRE
Responsible Responsible
X
X
X
X
X
X
X
X
SP
DESCRIPTION
ERROR
CODE
SP 19 Invalid Transaction Type (Mandatory). This
error 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
SP 20 Invalid Validity Indicator. No correction
necessary - resubmit records with this
error on your next file submission.
SP 21 Invalid MSP Code. No correction necessary
- resubmit records with this error on your
next file submission.
SP 22
SP 23
SP 24
SP 25
Invalid Diagnosis Code. No correction
necessary - resubmit records with this
error on your next file submission.
Invalid Remarks Code. No correction
necessary - resubmit records with this
error on your next file submission.
Invalid Coverage Type.
Valid Values:
‘J’ = Hospital Only
‘K’ = Medical Only
‘A’ = Hospital and Medical
‘U’ = Drug Only (network Rx)
‘V’ = Drug with Major Medical (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 Account (nonnetwork Rx)
‘4’ = Comprehensive Coverage –
Hosp/Med/Drug (non-network Rx)
‘5’ = Hospital and Drug (non-network Rx)
‘6’ = Medical and Drug (non-network Rx)
Invalid Insurer Name. Insurer name on the
Non-MSP Input record or associated MSP TIN
Reference File record for the insurer TIN has
an invalid insurer name. Correct and resend
the Non-MSP Input record or both the TIN
Reference File and MSP Input File records.
Spaces are allowed between words in an
134
COBC
RRE
Responsible Responsible
X
X
X
X
X
X
X
SP
ERROR
CODE
DESCRIPTION
COBC
RRE
Responsible Responsible
insurer plan name. Field may contain alpha
and/or numeric characters, commas, & - ' . @
# / : ;. Field cannot be blank. If the MSP
Insurers name is equal to SUPPLEMENT,
SUPPLEMENTAL, INSURER,
MISCELLANEOUS, CMS, ATTORNEY,
UNKNOWN, NONE, N/A, UN, MISC, NA, NO,
BC, BX, BS, BCBX, BLUE CROSS, BLUE
SHIELD, or MEDICARE, SP 25 error will
occur.
SP 26
SP 27
SP 28
SP 29
This error will also be returned if no Insurer
TIN was submitted on the MSP Input record.
Invalid Insurer Address 1 and/or Address 2.
Address field(s) on the associated TIN
Reference File record for the insurer TIN is/are
invalid. Correct and resend TIN Reference
File and MSP Input File records. Spaces are
allowed between words in a plan address.
Field may contain alpha and/or numeric
characters, commas, & - ' . @ # / : ;. Field
cannot be blank.
Invalid Insurer City. City field on the
associated TIN Reference File record for the
insurer TIN is invalid. Correct and resend the
TIN Reference File and MSP Input File record.
Field cannot contain numeric characters.
Spaces are allowed for multi-city word name.
If field is not used, field must contain spaces.
Field may contain alpha characters, commas,
& - ' . @ # / : ;.
Invalid Insurer State. State field on the
associated TIN Reference File record for the
insurer TIN is invalid. Correct and resend the
TIN Reference File and MSP Input File record.
Field may contain alpha characters. Alpha
characters provided must match U.S. Postal
State Abbreviation Table. When the Insurer’s
state does not match a state code on the U.S.
Postal Service state abbreviation table, SP28
error will occur.
Invalid Insurer Zip Code. Zip Code on the
associated TIN Reference File record for the
insurer TIN is invalid. Correct and resend the
TIN Reference File and the MSP Input File
record. First five positions must be numeric;
last four positions may be numeric or spaces.
135
X
X
X
X
SP
DESCRIPTION
ERROR
CODE
SP 30 Invalid Policy Number. If field is not used, field
must contain spaces. Field may contain alpha
and/or numeric characters, commas, & - ' . @
# / : ;.
SP 31 Invalid Effective Date (Mandatory). Field must
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 19500230 is not acceptable
(February cannot have 30 days). 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 SP 31.
SP 32
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. In this
case, continue to resend the record until the
individual is no longer an Active Covered
Individual or GHP coverage is terminated.
Invalid Termination Date (Mandatory). Field
must 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
19500230 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.
Termination date must be greater than 30 days
after the MSP Effective Date.
136
COBC
RRE
Responsible Responsible
X
X
X
SP
ERROR
CODE
DESCRIPTION
COBC
RRE
Responsible Responsible
SP 33
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. The RRE cannot
fix this error. Continue to send the record until
the individual is no longer considered to be an
Active Covered Individual or GHP coverage is
terminated.
Invalid Patient Relationship (Mandatory). Field
must contain numeric characters. Field cannot
be blank or contain alpha characters.
Acceptable numeric values are as follows:
01 = Beneficiary
02 = Spouse
03 = Child*
04 = Other
20 = Domestic Partner
X
SP 34
* Applies only for children covered under the
ESRD provision or disabled adult children
covered under the disability provision.
Invalid Policy Holder/Subscriber First Name.
Field may contain alpha and/or numeric
characters, spaces, commas, & - ' . @ # / : ;. If
field is not used, field must contain spaces.
X
SP 35
SP 36
SP 37
SP 38
SP 39
Invalid Policy Holder/Subscriber Last Name.
Field may contain alpha and/or numeric
characters, spaces, commas, & - ' . @ # / : ;. If
field is not used, field must contain spaces.
Invalid Policy Holder SSN. Field may contain
alpha and/or numeric characters, spaces,
commas, & - ' . @ # / : ;. If field is not used,
field must contain spaces.
Invalid Source Code. No correction
necessary - resubmit records with this
error on your next file submission.
Invalid Employee Information Data Code. No
correction necessary - resubmit records
with this error on your next file submission.
Invalid Employer Name. Employer Name on
the associated TIN Reference File record for
the Employer TIN is invalid. Correct and
resend the TIN Reference File and MSP Input
File record. Field must contain alpha and/or
numeric characters, commas, & - ' . @ # / : ;.
If field is not used, field must contain spaces.
137
X
X
X
X
X
SP
ERROR
CODE
DESCRIPTION
COBC
RRE
Responsible Responsible
(For those beneficiaries that are Working Aged
or Disabled, this field should always contain
the name of the actual employer.)
SP 40
SP 41
SP 42
SP 43
SP 44
This error will also be returned if no Employer
TIN was submitted on the MSP Input record.
Invalid Employer Address. Employer Address
on the associated TIN Reference File record
for the Employer TIN is invalid. Correct and
resend the TIN Reference File and MSP Input
File record. Field must contain alpha and/or
numeric characters, commas, & - ' . @ # / : ;.
If field is not used, field must contain spaces.
(For those beneficiaries that are working aged
or disabled, this field should always contain
the address of the actual employer.)
Invalid Employer City. Employer City on the
associated TIN Reference File record for the
Employer TIN is invalid. Correct and resend
the TIN Reference File and MSP Input File
record. Field may contain alpha and/or
numeric characters. If field is not used, field
must contain spaces. Valid characters include
commas, & - ' . @ # / : ;.
Invalid Employer State. Employer State on the
associated TIN Reference File record for the
Employer TIN is invalid. Correct and resend
the TIN Reference File and MSP Input File
record. Field must contain alpha characters.
Field cannot be blank. If a foreign country, use
'FC' for state code. Alpha characters provided
must match U.S. Postal State Abbreviation
Table.
Invalid Employer Zip Code. Employer Zip
Code on the associated TIN Reference File
record for the Employer TIN is invalid. Correct
and resend the TIN Reference File and MSP
Input File record. First five positions may be
numeric; the last four positions may be
spaces. Field cannot contain alpha
characters. Must be within valid zip code
range on zip code table. The first five digits
can be zeros, and last four can be blanks.
Invalid Insurance Group Policy Number. If
field is not used, field must contain spaces.
Field may contain alpha and/or numeric
138
X
X
X
X
X
SP
ERROR
CODE
SP 45
SP 46
SP 47
SP 48
SP 49
SP 50
SP 51
SP 52
DESCRIPTION
COBC
RRE
Responsible Responsible
characters, commas, & - ' . @ # / : ;.
Invalid Individual Policy Number. If field is not
used, field must contain spaces. Field may
contain alpha and/or numeric characters,
commas, & - ' . @ # / : ;.
Invalid Pre-Paid Health Plan Date. No
correction necessary - resubmit records
with this error on your next file submission.
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.
MSP auxiliary record not found for delete data
transaction. This edit occurs when an attempt
is made to delete a non-existent 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.
Invalid function for update or delete. No
correction necessary - resubmit records
with this error on your next file submission.
MSP auxiliary record has 17 occurrences and
none can be replaced. No correction
necessary - resubmit records with this
error on your next file submission.
Invalid patient relationship code (“PRC”).
(Mandatory) The MSP Code (Type) must
correspond with valid PRC as cited below.
MSP Code/Patient Relationship Codes
A = Working Aged
01 = Beneficiary
139
X
X
X
X
X
X
X
X
SP
ERROR
CODE
DESCRIPTION
COBC
RRE
Responsible Responsible
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
SP 53
SP 54
SP 55
SP 56
For example, you will receive this edit when
the MSP Code is equal to or determined to be
’A‘ ’G‘ or ’B‘ by the COBC and one of the
following occurs: 1) If the MSP Code is equal
to ’A‘ and the MSP patient relationship does
not equal ‘01’ and ‘02’ or 2) the MSP code is
equal to ’G‘ and the patient relationship does
not equal '01', '02'. '03', ‘04’ and ‘20’.
MSP Code ‘G’ or ‘B’ overlaps another Code
‘A’, ‘G’, or ‘B’. No correction necessary resubmit records with this error on your
next file submission.
MSP Code ‘A’ or ‘G’ has an effective date that
is 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.
MSP Effective Date is less than the earliest
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.
MSP pre-paid health plan date must equal or
be greater than the MSP Effective Date or less
140
X
X
X
X
SP
ERROR
CODE
SP 57
SP 58
SP 59
SP 60
SP 61
DESCRIPTION
COBC
RRE
Responsible Responsible
than MSP Termination Date. No correction
necessary - resubmit records with this
error on your next file submission.
Termination Date greater than 6 months
before date of accretion. No correction
necessary - resubmit records with this
error on your next file submission.
Invalid Coverage Type, MSP Code, and
validity indicator combination. Mapped
coverage type must equal ‘J’, ‘K’, or ‘A’. No
correction necessary - resubmit records
with this error on your next file submission.
Invalid insurer type and validity indicator
combination. RREs should not receive this
edit. No correction necessary - resubmit
records with this error on your next file
submission.
Other insurer type for same period on file (not
’J‘ or ’K‘). RRE submits a ’J‘ or ’K‘ insurer
type, but Medicare's CWF shows ’A‘ insurer
type. Insurer type does not match previously
submitted insurer type. Note: Edit only applies
to MSP codes.
A - Working Aged
B - ESRD EGHP
G - Disability EGHP
No correction necessary - resubmit records
with this error on your next file submission.
Other insurer type for same period on file (‘J‘
or ’K‘). RRE submits an ’A‘ insurer type, but
Medicare's CWF shows ’J‘ or ’K‘ insurer type.
Insurer type does not match previously
submitted insurer type.
Note: Edit only applies to MSP codes:
A - Working Aged
B - ESRD EGHP
G - Disability EGHP
No correction necessary - resubmit records
with this error on your next file submission.
141
X
X
X
X
X
SP
DESCRIPTION
ERROR
CODE
SP 62 Incoming termination date is less than MSP
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.
SP 66
SP 67
SP 69
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, the
RRE cannot fix this error but should continue
to send the record until the individual is no
longer considered to be an Active Covered
Individual.
MSP Effective Date is greater than the
Effective 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.
Incoming Termination Date is less than posted
Termination Date for Provident. SP 67 occurs
when the Termination Date on the
maintenance record is less than the
Termination Date on the Auxiliary record that
is to be updated.
No correction necessary - resubmit records
with this error on your next file submission.
Updating contractor number is not equal to the
header contractor number. CMS assigns the
contractor number.
No correction necessary - resubmit records
with this error on your next file submission.
142
COBC
RRE
Responsible Responsible
X
X
X
X
SP
DESCRIPTION
ERROR
CODE
SP 71 Attempting to change source code P-S. No
correction necessary - resubmit records
with this error on your next file submission.
SP 72
SP 73
SP 74
SP 75
SP 99
SP ES
Invalid transaction attempted. No correction
necessary - resubmit records with this
error on your next file submission.
Invalid Termination Date/Delete Transaction
attempted. Internal CMS use only. No
correction necessary - resubmit records
with this error on your next file submission.
Invalid - cannot update 'I' record. No
correction necessary - resubmit records
with this error on your next file submission.
Invalid transaction. Beneficiary does not have
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.
HICN required if individual is less than 45
years of age
Due to the employer size, an MSP occurrence
is not created. Check that the employer size
submitted was correct and continue to resend
the record on all subsequent quarterly file
submissions until an ‘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.
143
COBC
RRE
Responsible Responsible
X
X
X
X
X
X
X
Section 111 GHP Rx Error Codes
These codes only apply to records submitted for prescription drug coverage.
Error Code
Error Description
RX 01
Missing RX ID
RX 02
Missing RX BIN
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
144
Section 111 SEE (Small Employer Exception) Response Codes
SEE
Response
Codes
SA
SN
SP
Description
SEE-HICN accepted. Record bypassed and not submitted to CWF.
Disposition code of BY has been applied
SEE-HICN not-accepted. SEE HICN could not be confirmed. Record
processed as normal MSP occurrence. Disposition code should be used
to determine subsequent processing required.
SEE-HICN partially accepted. SEE HICN confirmed, but insurance
effective period outside of SEE effective period. Disposition code should
be used to determine subsequent processing required.
Section 111 Compliance Flag Codes
Compliance
Code
01
02
Description
An invalid insurer/TPA TIN was supplied in the MSP Input record Field
22. The corresponding TIN on the TIN Reference File could not be
validated by the COBC. The record was processed without the TIN.
Refer to the disposition code for results. Record must be resubmitted
with the correct insurer/TPA TIN in the next quarterly file submission
in order to comply with Section 111 requirements.
An invalid employer TIN was supplied in the MSP Input record Field
21. The corresponding TIN on the TIN Reference File could not be
validated by the COBC. The record was processed without the TIN.
Refer to the disposition code for results. Record must be resubmitted
with the correct employer TIN in the next quarterly file submission in
order to comply with Section 111 requirements.
145
Appendix E – MMSEA Section 111 BASIS Request Attachment
MMSEA Section 111 BASIS Request
Section 111 Reporter ID:
Date:
Section 111 Reporter Company Name:
SECTION I – Please list all persons to be given access to your BASIS account. MUST BE COMPLETED FOR ALL
REQUESTS
User Name
Title
E-mail Address
146
Telephone
Number
Indicate:
A – Add
R – Remove
User Mother Maiden
Name
SECTION II: AUTHORIZATION
Administrative Contact Name: ____________________________________________
Administrative Contact E-Mail Address: _____________________________________
Administrative Contact Phone Number: ___________________
______________________
Administrative Contact Signature
SECTION III: FOR COBC USE ONLY
Date Received:
Date Completed:
Date Plan Notified:
Method of Notification:
Processor Name:
Processor Signature:
Date:
__
147
Appendix F – MMSEA Section 111 HTTPS/SFTP Incoming File Naming Conventions
Files sent to the Enterprise File Transfer Facility GENTRAN mailboxes at the CMS Data Center should follow the naming convention
below.
File name IN ALL CAPITAL LETTERS
Example: GUID.RACFID.MIR.X.UNIQUEID.FILETYPE.W.ZIP
Incoming File Name Convention:
File Node
GUID
RACFID
MIR
X
Description
7 character Alphanumeric user ID generated by the
Individuals Authorized Access to CMS Computer
Services (IACS).
4-character RACF user ID.
Note: If you do not have RACF ID for the CMS
Data Center, insert NONE.
Always use the value of ‘MIR’ for Section 111 files.
Frequency of file transmission
M – MONTHLY
Q – QUARTERLY
UNIQUEID
FILETYPE
This is the letter R followed by the last 7 digits of
your Section 111 Reporter ID. If your Section 111
Reporter ID is 000001234 then this node should be
R0001234.
Code exactly as shown for the applications listed
below:
148
•
•
•
•
W
ZIP
. (Periods)
MRMSP for MSP Input File
MRTIN for TIN Reference File
MRNMSP for Non-MSP Input File
MRQRY for Query Only Input File
Code T for Test Data
Code P for Production Data
Only used when file compression is used and
automatically added to the file name by the ZIP
application, e.g., WINZIP or PKZIP.
Note: WINZIP version 9 or higher is required to
support long file names.
Delineators
GENTRAN Outgoing File Naming Conventions (GENTRAN Back to Section 111 Responsible Reporting Entity)
The filename created by the application will be sent unchanged to the mailbox. GENTRAN will then append a unique identifier to the
end of the file. When downloading the file from your organizational mailbox, you may change the file name in accordance with your
organizational naming requirements. Gentran file names are listed below. Please note the third or fourth node in the filename, which
is represented as ‘rrrrrrrr’, will be unique for each business partner.
UNIQUEID = The letter R followed by the last 7
digits of your Section 111 Reporter ID. If your
Section 111 Reporter ID is 000001234 then this
node should be R0001234.
pn = Sequentially assigned number
149
Test Response Filenames
Description
Dataset name for MSP Response
File
Mailbox Filename
T.UNIQUEID.MRMSP.Dyymmdd.Thhmmsst.pn
Dataset name for Non-MSP
Response File
T.UNIQUEID.MRNMSP.Dyymmdd.Thhmmsst.pn
Dataset name for Query Only
Response File
T.UNIQUEID.MRQRY.Dyymmdd.Thhmmsst.pn
Production Response Filenames
Description
Dataset name for MSP Response
File
Mailbox Filename
P.UNIQUEID.MRMSP.Dyymmdd.Thhmmsst.pn
Dataset name for Non-MSP
Response File
P.UNIQUEID.MRNMSP.Dyymmdd.Thhmmsst.pn
Dataset name for Query Only
Response File
P.UNIQUEID.MRQRY.Dyymmdd.Thhmmsst.pn
HTTPS File Size Limitation
There is a HTTP file size limit of 1.0GB, with or without compression.
CRLF Considerations
The CRLF (carriage return line feed) characters will be handled by Gentran.
150
ZIP Utility Software
At the present time GENTRAN cannot support multiple files within a single compressed file name. However, it is recommended that
files be compressed and can be sent with the .zip extension.
GENTRAN Access Requirements
To access GENTRAN, please use your GUID that was provided by the IACS system. This should be your 7-character user ID.
Section 111 Responsible Reporting Entities may only have 4 users associated with their mailboxes. Designated users are
identified by the reporting entity and approved by the COBC.
HTTPS GENTRAN Mailbox Access and System Requirements
Internet URL – https://gis.cms.hhs.gov:3443/mailbox
HTTP Screen Shot User Guides are available under the download section at http://www.cms.hhs.gov/COBAgreement/.
Trading Partner Firewall
Port 3443 is used for connectivity to the GENTRAN facility (do not use the typical Port 80 for HTTP or Port 443 for HTTPS).
Browser Requirements:
Microsoft Internet Explorer 5.x or later
CMS does recommend that EFT users/Business Partners use a Microsoft Operating Systems that is currently supported by Microsoft
and at the appropriate Service Pack Levels.
To eliminate the HTTPS Security Pop-up after you have downloaded the GENTRAN Certificate, the end user may need to update
his/her VeriSign Class 3 Certificate. Instructions are available from the CMMS Helpdesk at 1-800-927-8069.
151
FTP SSH Client GENTRAN Mailbox Access and System Requirements
CMS has experience with the Sterling FTP client. If you have another client that you would like to use, you just have to make sure it
has SSH version 2.
To configure your client you will need the following information:
Host Name/IP Address: GIS.CMS.HHS.GOV
Port Number: 10022
Trading Partner Firewall
TCP Port 10022 for SFTP with SSH is used for the SFTP sessions.
Sterling FTP Client Minimum Requirements (Sterling Commerce)
Operating System
UNIX
Microsoft Windows
Requirements
RAM 512MB
OS
AIX 5.3
Solaris 9
HPUX 11i
Suse Linux 8.2
Red Hat Linux 9
RAM 512 MB
OS
Windows NT 4 SP6
Windows 2000 Pro
Windows XP SP1
152
Mailbox File Retentions
Section 111 files will be retained in your mailbox for up to 6 days, including weekends.
153
Appendix G – 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 a primary plan to the
program under this title; 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.
154
(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-(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
155
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 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.
156
Appendix H – MMSEA Section 111 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).
USE OF AGENTS FOR PURPOSES OF THE REPORTING REQUIREMENTS AT 42 U.S.C. 1395y(b)(7)
Agents are NOT Responsible Reporting entities (RREs). However, 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 RREs.
CMS provides information on the method of identifying agents for reporting purposes in Section 6.1.1.2 of this User Guide.
157
| File Type | application/pdf |
| Author | PatWork |
| File Modified | 2018-04-12 |
| File Created | 2008-12-19 |