Medicare Advantage and Prescription Drug System

MARx collects, maintains (stores) and shares Medicare beneficiary eligibility and enrollment information and plan-related information.

General Medicare beneficiary information includes:

Name; Date of Birth (DOB); Medicare Beneficiary Identifier (MBI); Social Security Number (SSN); Date of Death (DOD); Medical Notes; eligibility date; representative payee contact information; beneficiary residential address; beneficiary state and county; Enrollment source code; Beneficiary Medicare secondary payer information; Race and Ethnicity.

Eligibility and enrollment information includes information used to determine a beneficiary's eligibility for Medicare benefits and information about their enrollment in a Medicare Advantage and/or Part D plan and includes:

Beneficiaries opt-out status for Part D; enrollment entitlements codes (e.g., disabled, retired); enrollment benefits (e.g., low-income subsidy); incarceration status; enrollment date; enrolled contract number; enrolled contract benefit package number; enrolled prescription drug plan information.

Beneficiary payment data includes:

Payer type code; enrollment entitlement code; direct bill indicator; adjustment indicator.

Beneficiary premium information pertains to a specific enrollment period and includes:

Premium effective date; premium type; premium amount.

MARx application users classified as Plan users are authenticated in Identity Management (IDM) where their user credentials are stored. MARx shares the User ID.

User credentials for MARx application and system users classified as CMS users are stored in the Enterprise User Administration (EUA) system. The User ID is shared with IDM and MARx.

MARx uses the information collected, maintained (stored) or shared for providing enrollment, payment, and premium services to Medicare beneficiaries, plans and CMS.

Data common to applications supporting the Medicare program is available, used and updated by MARx as needed to meet its mission.

General Medicare beneficiary information is initially collected when a new beneficiary enrolls in Medicare. MARx uses that information as input to transaction processing. When a beneficiary dies and the DOD is added in MARx, the beneficiary's enrollment is cancelled, and premiums are no longer collected.

MARx is not a publicly accessible system, Medicare beneficiaries cannot access MARx and do not enter PII directly. The Common Medicare Environment (CME) database tables are used and updated by many applications which support the Medicare program. Data used by MARx for transaction processing is validated for accuracy before used by MARx. Eligibility and enrollment information may be collected outside of MARx (Social Security Administration (SSA), Enrollment Data Base (EDB)) functionality in Medicare Enrollment and Premium Billing Systems (MEPBS) over time as a Medicare beneficiary's health status may change and additional entitlements are available. If, for example, a beneficiary is in hospice, the beneficiary's data is updated with this medical information. Enrollment may also be revised during health insurance open enrollment season. Some eligibility and enrollment data may be added as new information, updated, used in transaction processing and shared with applications internal [Medicare Beneficiary Database (MDB), Retiree Drug Subsidy RDS, Automated Plan Payment System (APPS), the Payment Reconciliation System (PRS), Risk Adjustment Suite of Systems (RASS), Division of Capitated Plan Audits (DCPA), Office of the Actuary (OACT)] and external [SSA, RRB ] to CMS as explained below:-

External:

SSA- MARx sends the Social Security Administration (SSA) Part C and Part D premium information for beneficiaries with Low-Income Subsidy (LIS), beneficiaries with Part B reduction and all SSA beneficiaries with SSA premium withholding or a change in premium withholding. SSA sends MARx responses to Part C and Part D premium information and a copy of its Medicare database.

RRB- MARx sends RRB Part C and Part D premium information for RRB beneficiaries with Part B reduction. RRB sends MARx responses for the information received.

Internal:

MEPBS- The Medicare Beneficiary Database (MBD) functionality in MEPBS receives notifications from SSA and others and builds notification messages that are sent to MARx. The MBD functionality in MEPBS sends notifications of changes to MARx for beneficiary addresses, hospice periods, Part D eligibility, secondary insurance, retiree drug subsidy periods, low-income subsidy, deeming, low-income territory and Medicaid data from Medicare Prescription Drug, Improvement, and Modernization Act (MMA) state files. MEPBS also forwards auto-enrollment and facilitated transaction files and Coordination of Beneficiary (COB) files that are distributed to plans. MARx receives transactions and builds notifications of updates including new enrollments, disenrollments, Managed Care Organization (MCO) corrections, plan changes, premium changes and beneficiary searches that are forwarded to MEPBS; RDS- The Retiree Drug Subsidy (RDS) system sends beneficiary retiree drug subsidy periods to MARx. MARx sends RDS rejected enrollments; APPS- MARx provides summarized payment and adjustment data to the APPS. APPS forwards adjustments to plan payments; PRS- uses the enrollment and payment data forwarded by MARx to perform reconciliation activities and generate reports; RASS- forwards risk adjustment factors to MARx and data included in the MARx month end processing; DCPA- MARx provides DCPA with Medicare secondary payer (MSP) beneficiary and plan data; OACT- provides MARx, the data needed to calculate payments for Medicare Advantage plans and Part D plans.

The User ID is used to access the MARx application and added to MARx data processed online. User activity online is also tracked by User ID. MARx users regularly enter PII to retrieve Medicare beneficiary records. The PII includes the beneficiary's Medicare Beneficiary Identifier (MBI); combination of the first name, last name, and plan contract number; Health Insurance Claim Number (HICN); SSN; and combination of the first name, last name, birth date and HICN, SSN or partial MBI.

• Social Security Number
• Name
• Medical Notes
• Date of Birth
• Mailing Address
• Date of Death
• Other - Medicare Beneficiary Identified (MBI); User ID for all users; incarceration status; enrollment date; enrolled contract number; enrolled contract benefit package number; enrolled prescription drug plan information; Race and Ethnicity

• Employees
• Public Citizens
• Business Partners/Contacts (Federal, state, local agencies)
• Vendors/Suppliers/Contractors
• Patients

SSN is maintained on Common Medicare Environment (CME) tables by MEPBS. SSN is populated in a field in each of the following files that are sent to plans: Part C Risk Adjustment Model Output Data File; Yearly Part C Risk Adjustment Model Output Data File; Risk Adjustment System (RAS) Prescription Drug Hierarchical Condition Category (RxHCC) Model Output Data File - aka Part D Risk Adjustment (RA) Model Output Data File; Yearly Risk Adjustment System (RAS) Prescription Drug Hierarchical Condition Category (RxHCC) Model Output Data File - aka Part D RA Model Output Data File; Medicare Advantage (MA) Full Dual Auto Assignment Notification Application Programming Interface (API); No Rx File.

All these files are produced by MEPBS. MARx simply splits the files into contract-specific files and distributes them to the plans. MARx does not produce any files that have SSN as a field.

Authority for maintenance of MARx is given under provisions of the Medicare Prescription Drug Improvement and Modernization Act, amending the Social Security Act (the Act) by adding Part D under Title XVIII (§ 1860D-15(c)(1)(C) and (d)(2), as described in 42 Code of Federal Regulation (CFR) 423.401, 42 CFR 417 and 422.

This system contains Protected Health Information (PHI) as defined by HHS regulation "Standards for Privacy of Individually Identifiable Health Information" (45 CFR Parts 160 and 164, 65 FR 82462 (Dec. 28, 00), as amended by 66 FR 12434 (Feb 26, 01)). Disclosures of PHI authorized by these routine uses may only be made if, and as, permitted or required by the "Standards of Privacy of Individually Identifiable Health Information."

• Within the OPDIV
• State/Local/Tribal
• Other Federal Entities

• Other Federal Agency/Agencies: PII is shared with SSA and RRB to withhold Medicare beneficiary Medicare Advantage and Part D premiums through SSA /RRB benefit processing.
• Private Sector: PII is disclosed to plans receiving monthly Medicare payments for Medicare Advantage and Part D plans under contract. PII from plan users is shared when a plan user accesses MARx online. PII for contractors is shared when they access MARx or test MARx processing.
• State or Local Agency/Agencies: PII is shared with states and territories participating in SPAP with an executed data sharing agreement in place. PII is shared with state Medicaid agencies to support care coordination for those enrolled in Medicare and Medicaid. Sharing is limited to those states that have an approved Memorandum of Understanding (MOU) in place.

SSA:

In addition to law requiring data sharing with SSA, there is an interagency agreement in place between SSA and CMS.

RRB:

There is an interagency agreement in place between RRB and CMS.

SPAP States and Territories:

CMS shares information with states to help pay for medications after an approved SPAP Data Sharing Agreement is established.

MMP States:

An executed MOU is required between the state and CMS for CMS to share Medicare data. The MOU covers all the Medicaid plans offered by the state. 

Data reports and files that are sent to the plans are available through the MARx User Interface. A database (DB2) table stores the names and dates of files sent to plans.

Data sent to Social Security Administration (SSA) and Railroad Retirement Board (RRB) is stored on a database (DB2) table.

Beneficiary:

A beneficiary's initial Medicare enrollment is completed at SSA. The beneficiary can access the Internet Privacy Policy at the SSA website to understand how SSA will manage their PII including sharing their information with CMS. The beneficiary chooses to enter their personal information to create their Medicare account.

The beneficiary may register an account with CMS using the medicare.gov and mymedicare.gov websites. The Online Services and Web Confidentiality Agreement is available for the beneficiary to review. On mymedicare.gov, the user can select Privacy Policy from the menu of available options. The beneficiary chooses to enter their personal information to create and use their account in mymedicare.gov.

When the beneficiary enrolls in Medicare with SSA, the general Medicare beneficiary information is transferred from SSA to CMS. This information is stored with the data common to applications supporting the Medicare program and available for MARx to use.

A beneficiary may elect to enroll in a Medicare Advantage plan and/or a Part plan directly with the plan. During enrollment, the plan informs the beneficiary of the purposes for which their PII will be used and of the routine uses of the PII.

To enroll in a plan, the beneficiary must provide the PII required by MARx to carry out normal business functions. By enrolling, the beneficiary accepts the purposes for which their PII will be used. If a beneficiary does not accept these purposes, they can choose to not enroll in the plan. 

CMS users and plan users: 

CMS users and plan users accept the terms and conditions specified in the System Use Notification before they are authenticated in IDM. The user approved these terms and conditions when they registered their user ID in either EUA or IDM. These users voluntarily provided their personal information to receive user IDs and access to CMS applications. 

PII is collected when the Medicare beneficiary initially enrolls in Medicare and added to when the Medicare beneficiary enrolls in a Medicare Advantage and/or Part D plan. If the beneficiary objects to providing their PII, their option is to not enroll in Medicare. MARx receives data only for those who have or are enrolled in Medicare plans.

Beneficiaries can choose to opt-out of the collection of their PII by choosing not to create an account in our system.

CMS users and Plan users cannot opt-out because they must be authenticated before they are granted access to MARx. It is required by IDM for authentication.

Beneficiary:

MARx does not notify and obtain consent from beneficiaries enrolled in Medicare Advantage or Part D plans when major system changes occur in MARx. MARx does not interact directly with enrolled beneficiaries. Consent from beneficiaries, if required, would have been received from systems that provide enrollment transactions to MARx.

CMS handles notifying and obtaining consent from beneficiaries enrolled in Medicare Advantage plans and Part D plans when there are major system changes in MARx. This may include issuing updates to the System of Record Notice published in the Federal Register. CMS also publishes the publicly available information about changes to the Medicare program that impact Medicare Advantage plans or Part D plans on CMS' publicly available websites including medicare.gov and mymedicare.gov. Information provided addresses business process updates required in MARx to support these changes.

CMS users: and plan users:

IDM and EUA are the source of PII when these users are authenticated before accessing MARx therefore the process lies within these systems.

Beneficiary:

Medicare beneficiaries may call 1-800-Medicare to report their PII may have been inappropriately obtained, used, or disclosed of their PII or to correct inaccurate PII.

The customer service representative at 1-800-Medicare would follow their procedure to determine which group needs to be notified about this information. It is likely the MAPD Help Desk would be the group. They will record the information per their procedure, notify the group responsible for the data in question indicate there may have been a privacy breach.

If the data in question is enrollment data, the MARx team will properly report the breach and resolve the issue.

If the data in question pertains to user credentials, the IDM team is responsible for privacy breach reporting and issue resolution for plan users. The EUA team and IDM team is responsible for privacy breach reporting and issue resolution for CMS users and plan users respectively. 

• Users: Plan and state users use MARx online to query beneficiary enrollment and premium data. CMS users use MARx online to perform permitted system, beneficiary, premium and payment functions.
• Administrators: MARx System Administrators - A limited number of CMS users are granted this role to perform MARx business functions typically not included in other CMS user roles. The MARx System Administrator role is granted access to a subset of MARx-related activities and not all activities. MARx System Administrator and other CMS user roles permit access to the same PII.
• Database Administrators (DBAs) - DBAs view PII in the environments where production data populates the database tables. In the lower environments, they handle table changes and their respective data changes as part of development activities. Production data access is triggered by request and is read-only and infrequent.
• Developers: CGI (not an acronym) CMS direct contractor system maintainer team members access PII as part of life cycle activities including testing and data validation.
• Contractors: CGI (not an acronym) CMS direct contractor system maintainer team members access PII as part of life cycle activities including testing and data validation. Business Operations (BusOps) - Executes jobs as part of their production operations support for MARx and related Medicare systems. They review batch production transaction activity and summarize the activity in reports sent to CMS managers and system maintainers. Note: This organization is not part of the CGI system maintainer team; they are under a separate contract with CMS.

User roles are managed as part of business requirements for a change request (CR). New roles, activities, and mapping to the MARx User Interface (UI) are defined in the User Stories approved by CMS business owners and product owners. Roles are defined per least functionality requirements - access is limited to the business functions required to fulfill that role. Data permissions support least privilege and business need-to-know requirements - within each role, a user's data permissions are limited to the information needed to execute and validate the business functions of that role.

A system user classified as a CMS user needs a Resource Access Control Facility (RACF) identifier (ID) before MARx access is granted along with specific job codes authorized in the Enterprise User Administration (EUA) system. The system user enters the requisite information online to request the RACF ID and job codes needed and submits it online. The same information is used if additional job codes are needed, and the system user already has a RACF ID. The RACF ID and job codes are reviewed and approved per CMS' predefined workflow. The workflow includes MARx COR and MARx Job Code Business Owner approval.

Upon receipt of the RACF ID and job code approvals, a MARx Security Administrator creates the MARx user accounts and specifies the permitted user role(s) for new system users. For existing system user accounts with new job codes, the MARx Security Administrator updates these MARx user accounts with the new permissions. All system users have access to PII.

Plan users need an IDM user ID before MARx access is granted. The plan users follow the procedures to request access and get approval from their designated External Point of Contact (EPOC) within their organizations. The EPOC approves all access requests and confirms requested roles and data permissions. 

A MARx Security Administrator is not permitted to change their user accounts regardless of environment. The MARx Business Owner and Information System Security Officer (ISSO) are different people. Read-only production data access is permitted to system maintainer team members according to the need-to-know and least privilege principles. MARx security testing is conducted by a group separate from the MARx development team. These practices support separation of duties and reduce the risk of collusion and insider threat activities. Adaptive Capabilities Testing (ACT) and audits are performed by independent third-party providers and are under contract with organizations not responsible for MARx.

CMS is required to provide role-based Information Security (IS) training to employees and contractors who have specialized roles within CMS' IS program in accordance with the Federal Information Security Management Act (FISMA) of 2002 and 5 CFR 930, Information Security Responsibilities for Employees Who Manage or Use Federal Information Systems. CMS is implementing annual IS training requirements for role-based groups. CMS encourages personnel to leverage training sessions that are offered by the Office of Information Technology (OIT) or the Office of Enterprise Information (OEI) such as briefings, forums, and seminars. Such training focuses on improving the security skills and competencies of the personnel who manage, design, develop, acquire, and administer CMS' information technology resources. CMS users are required to complete computer-based training (CBT) courses regarding information security and privacy awareness before receiving access to the CMS network and as part of the annual recertification process.

The MARx System Maintainer team members are required to complete corporate information security training when hired and annually thereafter. This includes attending security and privacy awareness training designed specifically to meet the needs of the CMS account. CGI's CMS account training coordinator tracks training activities and attendance.

Every Federal agency is legally required to manage its records. Records are the evidence of the agency's actions. Therefore, they must be managed properly for the agency to function effectively and to comply with Federal laws and regulations.

As defined in the CMS Records Schedule and approved by the National Archives and Records Administration (NARA), data retention and destruction of PII stored in MARx follow this guidance:

Medicare Advantage and Rx Plan Operations (MARPO) - Disposition Authority: N1-440-09-04

DISPOSITION: Temporary. Delete when data have been entered into the Master Files or database and verified, or when no longer required to support reconstruction of, or serves as a backup to, a master file or database, whichever is later. (Disposition Authority: NARA’s General Record Schedule GRS 5.1 and 5.2)

Beneficiary enrollment, premium and payment records - Temporary. Cutoff annually. Delete/destroy 6 years 3 months - Disposition Authority: pending NARA approval.

Medicare Advantage - Temporary. Cutoff annually. Delete/destroy 10 years after cutoff - Disposition Authority: N1-440-09-4, Item 1a.

Prescription Drug Records - Temporary. Cutoff annually. Delete/destroy 10 years after cutoff - Disposition Authority: N1-440-09-4, Item 1b.

Capitation Rate Records - Temporary. Cutoff annually. Delete/destroy 5 years after cutoff - Disposition Authority: N1-440-09-4, Item 1c.

Prescription Drug Events (PDEs) and Related Data - Temporary. Cutoff annually. Delete/destroy 20 years after cutoff - Disposition Authority: N1-440-09-4, Item 1d.

The following administrative and technical controls have been implemented to secure the PII stored and processed by MARx:

RACF; user ID and password-controlled access; firewall; front-end security; network technology.

Access to production data is controlled by RACF groups assigned to EUA job codes and IDM job roles and is limited to "read only" access except when authorized by DPO to use the MARx System Administrator role.

Any data change in the production database goes through a formal approval process. Compliance standards receive an annual review of the Assessment & Authorization documentation and controls.

Physical controls include controlled and limited access into the CMS Baltimore Data Center (BDC). Access to MARx at the BDC is restricted. No one on the MARx system maintainer team has physical access to the BDC.