Skip to main content

Medicare Online Support System

Privacy Impact Assessment (PIA) published by CMS as an Operating Division of the U.S. Department of Health and Human Services

Date signed: 3/7/2023

PIA Information for Medicare Online Support System
PIA QuestionsPIA Answers 
OPDIV:CMS 
PIA Unique Identifier:P-3998614-322077 
Name:Medicare Online Support System 
The subject of this PIA is which of the following?Major Application 
Identify the Enterprise Performance Lifecycle Phase of the system.Operate 
Is this a FISMA-Reportable system?Yes 
Does the system include a Website or online application available to and for the use of the general public?Yes 
Is this a new or existing system?Existing 
Does the system have Security Authorization (SA)?Yes 
Date of Security Authorization4/2/2025 
Indicate the following reason(s) for updating this PIA. Choose from the following options.Significant System Management Change 
Describe in further detail any changes to the system that have occurred since the last PIA.

Durable Medical Equipment (DME) Supplier site https://www.medicare.gov/medical-equipment-suppliers/ was added in December 2020 for Medicare Innovation & Emerging Tech (MCIET) ( Formerly Procedure Price Lookup (PPL) ). Medicare Coverage Tools (MCT) is now utilizing Zendesk, a Federal Risk and Authorization Management Program (FedRAMP)-approved software as a service (SaaS), used during Open Enrollment to consolidate a wide variety of support and feedback communications into a single service desk for Medicare Plan Finder. 

The addition of connectivity between BEDAP and IDRC Snowflake in November 2023 via an AWS Privatelink in order for BEDAP to retrieve data from IDRC to enable BEDAP to show claims data on the Medicare website. The data sharing is one-way directional, from IDRC to BEDAP. BEDAP is not sharing data with IDRC. 

 
Describe the purpose of the system

The Medicare Online Support System (MOSS) is a data analytics platform to provide claim, payment, cost, and other information pertinent to authenticated users.

Medicare innovation & Emerging tech (MCiEt) (Formerly Procedure Price Lookup (PPL))

The MCiEt (formerly known as PPL) is a subsystem to the MOSS System. The MCiEt system is hosted in the CMS private cloud located in the AWS data center in the AWS East Region (North Virginia). The AWS data center is operated by contract personnel.

The MCiEt system product suite consists of two web based applications (Procedure Price Lookup tool & DME Supplier Directory), API’s, Ontology, and Location Widgets. Specific details for each product are outlined in the content below.

This platform matured to become a source of much richer and more useful cost data, broadly supporting the Digital Senior initiative and the agency’s efforts to provide transparency in the Medicare program. It is responsively designed to work on desktop and mobile screens; for accessibility and ease of use; and architected to support rapid release cycles. An Office Pricing Application Programming Interface (API) offers regional average physician pricing data for office visit procedures in the office setting for consumption by Care Choice Experience (CCXP). The DME Supplier code and search for suppliers near them, in addition to searching for specific types of supplier using an ontology-based search.

MCT

The Medicare Coverage Tools (MCT) application was added to MOSS in mid-2019. It provides Medicare beneficiaries, family members, caregivers, advocates, State Health Insurance Assistance Program (SHIP) Counselors, Call Center Representatives, and health care providers with one central point to view, compare and select prescription drug and health plan choices by conducting a general search within their geographical area. 

BEDAP

Beneficiary Experience Data Analytics Portal (BEDAP) provides a single source of truth for Medicare Beneficiary data to equip CMS' communications channels with the data to support an improved omnichannel experience across the Medicare program including Medicare.gov, MCT, 1-800-Medicare, publications and outbound outreach such as email and other direct response tactics.

PQDC

Provider Quality Data Catalog (PQDC) is a cloud-based computer platform hosted by Acquia (an Amazon Web Services reseller focusing on Drupal applications) that CMS has contracted in order to provide the public with access to CMS “released and cleared datasets” about a broad range of Medicare, Medicaid and other health-related topics. The information is currently published to data.medicare.gov. PQDC will be part of cms.gov.

CCXP

Care Compare (CCXP) is an integrated tool on Medicare.gov to find, select, and compare providers & services that meet a beneficiary's needs across their entire health journey using Medicare. While the target audience for Care Compare (CCXP) are beneficiaries and their caregivers, the tool also serves:
•  Professional data users / healthcare industry
•   Policy makers / Medicare governing bodies
• Oversight and watchdog agencies
Care Compare brings together eight different provider-type settings into one cohesive experience, where users can learn about healthcare quality, outcomes, and patient survey information to inform their own care choices.

 
Describe the type of information the system will collect, maintain (store), or share. (Subsequent questions will identify if this information is PII and ask about the specific data elements)

MCIET Application

The Procedure Price Lookup (PPL) is a subsystem to the MOSS System. The PPL system is hosted in the CMS private cloud located in the Amazon Web Services (AWS) data center in the AWS East Region (North Virginia). The AWS data center is operated by contract personnel.

The web-based application known as the Procedure Price Lookup tool assists people with comparing cost and copays for certain procedures in hospital outpatient departments and ambulatory surgery centers.

The PPL application supports the agency’s efforts to provide cost transparency in the Medicare program.
● Responsively designed to work on desktop, laptop, tablet & mobile phone screens
● Designed for accessibility and ease of use
● Architected to support rapid release cycles

he PPL Search by Current Procedural Terminology (CPT) code or Term describing the procedure displays national averages for the amount Medicare pays the hospital or surgery center and the national average copay amount a beneficiary with no Medicare supplement insurance would pay the provider.

Consumer Goals:
●  Understand there is a difference in cost between Hospital Outpatient (HO) & Ambulatory Surgery Center (ASC).
●  Awareness that they have options - cost & where they have the procedure done
●  Provide data that will help initiate dialogue for the patients

MCIET verifies access to the Current Procedural Terminology (CPT) data through a table of valid American Medical Association (AMA) license keys received from the AMA API. Once verified, AMA License keys are encrypted and stored in Elasticache to reduce the required number of calls to the AMA API. The license keys are valid until 12/31/XXXX at midnight. At this time Elasticache will be refreshed to check that the stored license keys are valid for the next calendar year.

The MCIET does not contain personal identifiable information (PII) or Health Insurance Portability and Accountability Act (HIPPA) data. The site will be accessible from the Medicare.gov website at https://www.medicare.gov/procedure-price-lookup/. 

Durable Medical Equipment Supplier Site

The redesigned Durable Medical Equipment (DME) Supplier Site was made publicly accessible in December 2020. The business drivers for the new Supplier site were to reduce volume to the call center related to DME related inquiries, and to enhance the overall user experience, surfacing DME and Competitive Bid related information in a way that is easily consumed by end users. A large percentage of calls to the call center are related to DME questions.  The legacy supplier site was confusing and did not provide Medicare beneficiaries with adequate information.  The goal for the new site was to provide a more intuitive user experience with search fueled by an ontology to better meet users' mental models as they search for DME information.  Beneficiaries are able to enter their zip code and search for suppliers near them.  They are also able to search for specific types of supplies using an ontology-based search that is linked to CPT/Healthcare Common Procedure Coding System (HCPCS) codes.  

The Supplier site does not contain protected health information (PHI) or PII data. Cost data is provided from the publicly available Durable Medical Equipment, Prosthetics, Orthotics, & Supplies (DMEPOS) fee schedule file. This cost file is provided on a quarterly basis and will feed future releases of the Directory.  The content to be included in the new Supplier Site is static content grabbed from Provider Enrollment, Chain and Ownership System (PECOS) and Integrated Data Repository (IDR) extracts and does not contain PHI or PII data. All data is publicly available data. PECOS provides the public Durable Medical Equipment (DME) supplier information, IDR provides public DME volume/utilization. The site is accessible from the Medicare.gov website at https://www.medicare.gov/medical-equipment-suppliers.

Office Pricing API

An API developed and maintained by the PPL team to expose regional average physician pricing data for office-visit procedures in the office setting for consumption by the CCXP team. It was added into MOSS in the summer of 2019. There is no PII / PHI data.

DME Ontology
DME Ontology is an ontology API service hosted in CMS cloud (AWS). It contains “DMEPOS” ontology that allows clients to search for durable medical equipment (DME) for given search terms. The service also provides endpoints to obtain taxonomies stored as part of the “DMEPOS” ontology, and to get a list of metadata terms, aliases, and metadata about these terms.

DME Ontology is accessed using an API key. Contract personnel manage DME Ontology API keys and their lifecycle. The contract team stores the DME Ontology API key on AWS Secrets Manager so that it can be used by the DME API.

DME API service integrates with DME Ontology service for supplier search purposes, querying the DME Ontology API to obtain durable medical equipment for given search terms and relevant taxonomy categories. Then, DME API uses this data to find suppliers for given search terms and location.


DME Natural Language Processing

DME Natural Language Processing is an API service that is hosted in CMS AWS cloud. It acts as an intermediary between raw text entered into the Supplier Directory site and the DME Ontology search. For a given raw text search, the DME Natural Language Processing (NLP) API will return Ontology metadata tags found in the raw text search. The site then uses these metadata tags when searching using the DME Ontology.

DME Natural language processing is accessed using an API key. Contract personnel manage DME NLP API keys and their lifecycle. The contract team stores the DME NLP API key on AWS Secrets Manager so that it can be used by the DME API.


Global Search ETL
Global Search terms are pulled from Google Analytics using an AWS Lambda function that runs on a schedule (1st of every month). The Lambda function queries Google Analytics using Google API for the terms searched within the last 30 days and sorts the results by the number of searches for each term. Then, the global search term data is stored in a DynamoDB table. Search terms stored in the table have a time to live (TTL) value of 6 months. Global Search terms can be queried from the DynamoDB table using the indices: date, search term or the search rank (rank based on number of searches, 1 being the most searched).

MCiEt Location Widgets

Location Widget - Medicare Diabetes Prevention Program (MDPP)
The Medicare Diabetes Prevention Program (MDPP) is a benefit available to all Medicare beneficiaries should they meet certain criteria. In an effort to better connect individuals with programs in their area, the “location widget” allows individuals to enter a location from the MDPP coverage page to be passed through to a results page hosted by the MCiEt team. From the Results page, beneficiaries are able to refine their search using a standard set of filters that allows for location to be adjusted. In addition, a details page includes further information about the organization providing the service. Data is sourced via data.cms.gov and is updated quarterly. Google analytic tagging has been implemented by our MCiEt team providing a method for ongoing tracking and monitoring usage of the widget.

Location Widget - Opioid Treatment Program (OTP) Treatment for Substance Use Disorder involving opiates is a benefit available to all Medicare beneficiaries via Opioid Treatment Program providers. In an effort to better connect individuals with programs in their area, the “location widget” allows individuals to enter a location from the OTP coverage page to be passed through to a results page hosted by the MCiEt team. From the Results page, beneficiaries are able to refine their search using a standard set of filters that allows for location to be adjusted. In addition, a details page includes further information about the organization providing the service. Data is sourced via data.cms.gov and is updated weekly.  Google analytic tagging has been implemented by our MCiEt team providing a method for ongoing tracking and monitoring usage of the widget.

MCT

MOSS will also include the Medicare Coverage Tools (MCT) application which provides Medicare beneficiaries, family members, caregivers, advocates, and health care providers with one central point to view, compare and select prescription drug and health plan choices.

Collected Information: 

MCT offers three core user experiences:

  1. Anonymous Beneficiary
  2. Authenticated Beneficiary
  3. Customer Service Representative (CSR)

Each of these offers subtle variances with respect to what external systems integrations are involved and how those integrations are implemented.

MCT interfaces with the following external systems to support the required user functionality and the core MCT user experiences:

The Anonymous Beneficiary experience collects the zip code and county of users of the public website to provide relevant plan search results. Zip & County data is logged to Splunk as URL query parameters and retained for 7 years. Optional features collect prescription drug and pharmacy data to estimate total annual drug costs. Anonymous Beneficiary Drug & Pharmacy preferences are stored locally in the browser session and not collected by the application at all. Lastly, the Anonymous Beneficiary Experience collects all the data included on Medicare Enrollment forms

Medicare Coverage Tools (MCT) obtains the following PII/PHI from the MCT User Interface (UI) and integrations with the Beneficiary Experience Data Analytics Platform (BEDAP), Scalable Login System (SLSx), and Next Generation Desktop (NGD), depending on the user experience (Anonymous, Authenticated, or Customer Service Representative (CSR). Enrollment requests are stored in the MCT Database and transactionally passed to the Health Plan Management System (HPMS) Online enrollment center (OEC) application programming interface (API) for plans to download in bulk in the HPMS System. Enrollment Requests are retained in the MCT Database for 7 years. Enrollment Confirmation Data (Confirmation number, Plan ID, Plan name, Prospective member phone number) is sent to the Medicare Message Center API (MAX) so beneficiaries have a record of their enrollment and can reach out to plans if there is a problem.

PII/PHI collected, stored, and transmitted by MCT includes:

Plan accessibility format preference, Beneficiary Address, Beneficiary Birth date, Beneficiary  Enrollment Confirmation number, Plan Contact ID, Plan Contract ID, Beneficiary County, Beneficiary Current and Future  Low Income Subsidy (LIS) status, Beneficiary date of death, Beneficiary Dual Medicare/Medicaid eligibility information, Beneficiary Email address, Beneficiary Emergency contact name, phone, and relation, Beneficiary Sex, Beneficiary Health insurance claim number (HICN), Beneficiary HICN history, Long Term Care Facility name and address, Beneficiary Medicare Beneficiary Identifiers (MBI), Beneficiary MBI history, Plan Name, Other coverage name, ID, and group, Enrollment for the Special enrollment period (SEP) reason codes, Beneficiary Part A effective date, Beneficiary part A stop date, Beneficiary Part B effective date, Beneficiary part B stop date, Beneficiary Part C coverage information, Beneficiary Part D coverage information, Beneficiary other insurance, Plan ID, Plan name, Plan year, Premium direct pay preference, Premium withhold preference, Prescription drug event information (PDEs), Beneficiary Primary care physician, Plan Segment ID, Beneficiary Spouse work status, Beneficiary Social security number (SSN) (optional for dual eligible special needs plans), Beneficiary zip code, Beneficiary Work status

 

The Customer Service Representative (CSR) experience collects beneficiary HICN/MBI and CSR Activity ID from the Next Generation Desktop (NGD). This allows MCT to retrieve & display the correct beneficiary data from BEDAP to CSRs after they have authenticated themselves and their callers in NGD. CSRs can update the beneficiaries' saved drug list and saved pharmacy list. This data is retained for 7 years.

All three experiences send data through the MCT API which is routed through Akamai & API Manager (aka Kong). This means that Zip & FIPS and other API query parameters are passed through those systems and may be logged.

MCT obtains Medicare Advantage Policy data, Prescription Drug Plan data, Drug and Pharmacy data, and SPS/ADAP data from HPMS as well as Drug data from RxNorm, PAP data from RxAssist, and Medigap Plan Data from CSG.

Stored and Shared Information:

The collected data from HPMS will be stored in AWS relational database service (RDS) databases. The user zip code and county data will not be stored in any database but may be logged in Splunk as parameters to calls to the MCT API.

MCT stores and transfers PII/PHI from internal integrations with BEDAP and external CMS system integrations. 

PII/PHI collected, stored, and transmitted by MCT includes:

Plan accessibility format preference, Beneficiary Address, Beneficiary Birth date, Beneficiary  Enrollment Confirmation number, Plan Contact ID, Plan Contract ID, Beneficiary County, Beneficiary Current and Future  Low Income Subsidy (LIS) status, Beneficiary date of death, Beneficiary Dual Medicare/Medicaid eligibility information, Beneficiary Email address, Beneficiary Emergency contact name, phone, and relation, Beneficiary Sex, Beneficiary Health insurance claim number (HICN), Beneficiary HICN history, Long Term Care Facility name and address, Beneficiary Medicare Beneficiary Identifiers (MBI), Beneficiary MBI history, Plan Name, Other coverage name, ID, and group, Enrollment for the Special enrollment period (SEP) reason codes, Beneficiary Part A effective date, Beneficiary part A stop date, Beneficiary Part B effective date, Beneficiary part B stop date, Beneficiary Part C coverage information, Beneficiary Part D coverage information, Beneficiary Other Insurance,, Plan ID, Plan name, Plan year, Premium direct pay preference, Premium withhold preference, Prescription drug event information (PDEs), Beneficiary Primary care physician, Plan Segment ID, Beneficiary Spouse work status, Beneficiary Social security number (SSN) (optional for dual eligible special needs plans), Beneficiary zip code, Beneficiary Work status.

MCT users utilize Zendesk, a FedRAMP-approved SaaS, during Open Enrollment to consolidate a wide variety of support and feedback communications into a single service desk for Medicare Plan Finder. The rollout includes a web portal for users to submit support requests to and agents to respond to support requests from.  Support requests can also be submitted via email. The web portal also contains a self-service knowledge base feature that will gradually be built up to answer common user and stakeholder questions.

The following information is collected via Zendesk tickets and shared via Slack/Jira integrations:

Plan details including name, plan number, and segment ID;
Pharmacy information including name and National Provider Identifier (NPI);
Drug information including names, National Drug Codes (NDCs), and pricing information;
Screenshots of the Medicare Plan Finder (MPF) site.
Zendesk is not utilized to collect any beneficiary data.

BEDAP

BEDAP does not collect data directly – It sources data from other systems within CMS.

BEDAP stores personally identifiable/personal health information (PII/PHI) in AWS S3, RDS databases AWS Redshift and Vertica about Medicare beneficiaries, including eligibility & enrollment, Medicare claims, digital services utilization, email delivery vendor, and call center contact history.

Information stored by BEDAP for the system support staff, CMS employees and direct contractors, includes their username and business email address. Password information for BEDAP supporting staff is stored within the EUA system and/or as local user accounts. No password data is sent or stored in clear text.

BEDAP shares prescription drug events, subsidy eligibility, plan enrollment, and demographic details with MCT to facilitate a personalized plan shopping experience. BEDAP provides identity verification services to MyMedicare by providing metadata about beneficiaries. BEDAP works with outreach vendor Granicus (General Services Administration (GSA)-contracted mail vendors facilitated through Gentran) to drive targeted and relevant outbound communication. The BEDAP team ensures that systems with whom data is shared have a Data Use Agreement (DUA) that covers the data that is shared (if applicable), and data will be shared in a manner pursuant to the relevant System Interconnection Agreement or Memorandum of Understanding.

BEDAP retrieves the following datasets from IDRC Snowflake:
●        Medicare Part A and B via NCH via MQR/MQA
●        Medicare Part A and B via Shared Systems (MCS, VMS and FISS)
●        Medicare Part C Encounters via EDPS
●        Medicare Part D Prescription Drug Events (PDE) via DDPS
●        Medicare Part A and B Payment Standardization Data
●        Medicare Beneficiary Entitlement and Enrollment via CME (MDB, EDB
●        Medicare Provider via NPPES, PECOS
●        National Council for Prescription Drug Program (NCPDP)
●        Medicare Advantage/Part D Contract via HPMS
●        Reference data - National Drug Code(NDC) and RxNorm(FDB, MDDB)
●        Reference data - Diagnosis code, HCPCS code, Procedure code, Geographic code

PQDC

System administrators log on with a user ID and password. 

CMS uses PQDC to store and publish ‘released and cleared datasets about a broad range of Medicare, Medicaid and healthcare-related topics, such as: quality of care information on every Medicare and Medicaid-certified nursing home in the US; business contact information about physicians and other healthcare professionals enrolled as Medicare providers.

Information included in those datasets include physician name, business address, National Provider Identifier (NPI), sex. PQDC does not maintain or collect this data.  All of the data available and published is provided by other CMS systems, which directly collect and store the information within their own information systems.  

CCXP

All info comes from data.medicare.gov, the data that is collected is parsed and stored locally for the user to use for about a month. No sensitive data is taken from medicare.gov and no sensitive data is stored or exposed; the data consists of mostly facility information and demographics.

 
Provide an overview of the system and describe the information it will collect, maintain (store), or share, either permanently or temporarily.

Medicare Online Support System (MOSS) is a family of systems in development, including  MCIET, MCT, BEDAP, PQDC, and CCXP.

MCIET

The MCIET application stores the National Average total payment amount established & made by Medicare, National Average copayment amount for the beneficiary without Medicare supplemental insurance, at the procedure level for Ambulatory Surgical Center (ASC) and Hospital Outpatient (OPPS) care settings.

The Hospital Outpatient and ASC Cost comparison data is stored in the data warehouse database. In addition, the source file is retained for a period of 1 year. The Office Pricing data shared with CCXP is not sensitive data.  PPL data does not contain any PII besides the user credentials.  Supplier Site is static content from PECOS and IDR extracts and does not contain PHI or PII data. Provider Enrollment, Chain and Ownership System (PECOS) provides the public Durable Medical Equipment (DME) supplier information, and IDR provides public DME volume/utilization.

MCIET data does not contain any PII besides the user credentials.

MCT

MCT offers three core user experiences:

  1. Anonymous Beneficiary
  2. Authenticated Beneficiary
  3. Customer Service Representative (CSR)

Each of these offers subtle variances with respect to what external systems integrations are involved and how those integrations are implemented.

MCT interfaces with the following external systems to support the required user functionality and the core MCT user experiences:

The Anonymous Beneficiary experience collects the zip code and county of users of the public website to provide relevant plan search results. Zip & County data is logged to Splunk as URL query parameters and retained for 7 years. Optional features collect prescription drug and pharmacy data to estimate total annual drug costs. Anonymous Beneficiary Drug & Pharmacy preferences are stored locally in the browser session and not collected by the application at all. Lastly, the Anonymous Beneficiary Experience collects all the data included on Medicare Enrollment forms 

Medicare Coverage Tools (MCT) obtains the following PII/PHI from the MCT User Interface (UI) and integrations with the Beneficiary Experience Data Analytics Platform (BEDAP), Scalable Login System (SLSx), and Next Generation Desktop (NGD), depending on the user experience (Anonymous, Authenticated, or Customer Service Representative (CSR). Enrollment requests are stored in the MCT Database and transactionally passed to the Health Plan Management System (HPMS) Online enrollment center (OEC) application programming interface (API) for plans to download in bulk in the HPMS System. Enrollment Requests are retained in the MCT Database for 7 years. Enrollment Confirmation Data (Confirmation number, Plan ID, Plan name, Prospective member phone number) is sent to the Medicare Message Center API (MAX) so beneficiaries have a record of their enrollment and can reach out to plans if there is a problem.

PII/PHI collected, stored, and transmitted by MCT includes:

Plan accessibility format preference, Beneficiary Address, Beneficiary Birth date, Beneficiary  Enrollment Confirmation number, Plan Contact ID, Plan Contract ID, Beneficiary County, Beneficiary Current and Future  Low Income Subsidy (LIS) status, Beneficiary date of death, Beneficiary Dual Medicare/Medicaid eligibility information, Beneficiary Email address, Beneficiary Emergency contact name, phone, and relation, Beneficiary Sex, Beneficiary Health insurance claim number (HICN), Beneficiary HICN history, Long Term Care Facility name and address, Beneficiary Medicare Beneficiary Identifiers (MBI), Beneficiary MBI history, Plan Name, Other coverage name, ID, and group, Enrollment for the Special enrollment period (SEP) reason codes, Beneficiary Part A effective date, Beneficiary part A stop date, Beneficiary Part B effective date, Beneficiary part B stop date, Beneficiary Part C coverage information, Beneficiary Part D coverage information, Beneficiary  other insurance, Plan ID, Plan name, Plan year, Premium direct pay preference, Premium withhold preference, Prescription drug event information (PDEs), Beneficiary Primary care physician, Plan Segment ID, Beneficiary Spouse work status, Beneficiary Social security number (SSN) (optional for dual eligible special needs plans), Beneficiary zip code, Beneficiary Work status.

The Authenticated Beneficiary experience collects beneficiary MBIs from the Scalable Login System (SLSx) service after successful authentication so beneficiary data can be retrieved from Beneficiary Experience Data Analytics Platform (BEDAP). Retrieved data from BEDAP (Beneficiary Identification (Birth Date, Name, SSN, Sex, Full Mailing Address, and County), Email Address, HICN/MBI, HICN/MBI history, Part A Effective Date, Part stop date, Part B Effective Date, Part B stop date,  other insurance, Date of Death, Current Coverage, Future Coverage, Current LIS Status, Future LIS Status, Dual Medicare/Medicaid Status, and Recent Prescription Drug Claims) is stored in the MCT database along with the beneficiaries saved drug list and saved pharmacy list. This data is retained for 7 years. SLSx is also utilized to allow an authenticated user to easily move back and forth from MCT to Medicare.gov/mbp (MBP) and Medicare Consistent Header (CH) via the Akamai Global Session Header. No PII is exchanged. Enrollment Confirmation Data (Confirmation number, Plan ID, Plan name, 

The Customer Service Representative (CSR) experience collects beneficiary HICN/MBI and CSR Activity ID from the Next Generation Desktop (NGD). This allows MCT to retrieve & display the correct beneficiary data from BEDAP to CSRs after they have authenticated themselves and their callers in NGD. CSRs can update the beneficiaries' saved drug list and saved pharmacy list. This data is retained for 7 years.

All three experiences send data (user type, unique identifiers, logged-in state, year part) to LaunchDarkly to evaluate feature flags. Event from LaunchDarkly is exported to MCT`s analytics environment using AWS Kinesis  No PII is sent to LaunchDarkly or AWS Kinesis. 

All three experiences send data through the MCT API which is routed through Akamai & API Manager (aka Kong). This means that Zip & FIPS and other API query parameters are passed through those systems and may be logged.

MCT obtains Medicare Advantage Policy data, Prescription Drug Plan data, Drug and Pharmacy data, and SPS/ADAP data from HPMS as well as Drug data from RxNorm, PAP data from RxAssist, and Medigap Plan Data from CSG.

User zip code and county data logged in Splunk is archived and stored for 1 year should any audit of the system need to take place.

MCT stores and transfers PII/PHI from internal integrations with BEDAP and external CMS system integrations. 

PII/PHI collected, stored, and transmitted by MCT includes:

Plan accessibility format preference, Beneficiary Address, Beneficiary Birth date, Beneficiary  Enrollment Confirmation number, Plan Contact ID, Plan Contract ID, Beneficiary County, Beneficiary Current and Future  Low Income Subsidy (LIS) status, Beneficiary date of death, Beneficiary Dual Medicare/Medicaid eligibility information, Beneficiary Email address, Beneficiary Emergency contact name, phone, and relation, Beneficiary Sex, Beneficiary Health insurance claim number (HICN), Beneficiary HICN history, Long Term Care Facility name and address, Beneficiary Medicare Beneficiary Identifiers (MBI), Beneficiary MBI history, Plan Name, Other coverage name, ID, and group, Enrollment for the Special enrollment period (SEP) reason codes, Beneficiary Part A effective date, Beneficiary Part A stop date, Beneficiary Part B effective date, Beneficiary part b stop date, Beneficiary Part C coverage information, Beneficiary Part D coverage information, Beneficiary other insurance, Plan ID, Plan name, Plan year, Premium direct pay preference, Premium withhold preference, Prescription drug event information (PDEs), Beneficiary Primary care physician, Plan Segment ID, Beneficiary Spouse work status, Beneficiary Social security number (SSN) (optional for dual eligible special needs plans), Beneficiary zip code, Beneficiary Work status.

This data is stored in a separate database from the HPMS collected data.

The following information is collected via Zendesk tickets and shared by MCT users via Slack/Jira integrations:

Plan details including name, plan number, and segment ID;
Pharmacy information including name and National Provider Identifier (NPI);
Drug information including names, National Drug Codes (NDCs), and pricing information;
Screenshots of the Medicare Plan Finder (MPF) site.

Zendesk is not utilized to collect any beneficiary data.

BEDAP

BEDAP stores PII/PHI about Medicare beneficiaries, including eligibility & enrollment, Medicare claims (including prescription drug events), digital services utilization, email interactions (subscribes/unsubscribes/clicks/opens), Short Message Service (SMS) interactions (subscribes/unsubscribes/replies), and call center contact history. In the future, BEDAP may also store data from the Federal Trade Commission (FTC) related to do-not-call list membership.

BEDAP retrieves the following datasets from IDRC Snowflake:
●        Medicare Part A and B via NCH via MQR/MQA
●        Medicare Part A and B via Shared Systems (MCS, VMS and FISS)
●        Medicare Part C Encounters via EDPS
●        Medicare Part D Prescription Drug Events (PDE) via DDPS
●        Medicare Part A and B Payment Standardization Data
●        Medicare Beneficiary Entitlement and Enrollment via CME (MDB, EDB
●        Medicare Provider via NPPES, PECOS
●        National Council for Prescription Drug Program (NCPDP)
●        Medicare Advantage/Part D Contract via HPMS
●        Reference data - National Drug Code(NDC) and RxNorm(FDB, MDDB)
●        Reference data - Diagnosis code, HCPCS code, Procedure code, Geographic code

PQDC

Provider Quality Data Catalog (PQDC) is a cloud-based computer platform hosted by Acquia (an Amazon Web Services reseller focusing on Drupal applications) with which CMS has contracted to provide the public with access to CMS “released and cleared datasets” about a broad range of Medicare, Medicaid and other health-related topics. The information is currently published to data.medicare.gov, PQDC will be part of cms.gov. All datasets are uploaded to the PQDC platform by CMS employees and direct contractors by an encrypted method, such as Security File Transfer Protocol (SFTP).  Information included in those datasets include physician name, business address, National Provider Identifier (NPI), and sex. All CMS-approved PQDC publishers (other CMS systems) retain ownership and responsibility for the information contained within any datasets published. Once published, the information is readily downloadable without creating a user account. The individuals who may access the data are members of the general public.

System administrators log on with a user ID and password. System administrators are CMS employees and direct contractors. Login credentials are maintained for as long as the system user requires access.

CCXP

The information being collected from data.medicare.gov is all facility information (address, phone, etc.) and some demographic information, all of which is public information.

System administrators log on with a user ID and password. System administrators are CMS employees and direct contractors. Login credentials are maintained for as long as the system user requires access.

 
Does the system collect, maintain, use or share PII?Yes 
Indicate the type of PII that the system will collect or maintain.
  • Social Security Number
  • Name
  • E-Mail Address
  • Phone Numbers
  • Medical Notes
  • Date of Birth
  • Mailing Address
  • Medical Records Number
  • Financial Account Info
  • Employment Status
  • Date of Death
  • Therapy records
  • Other - Other - PPL: Other - User ID and password for public Consumers. EUA user ID and password for employees and direct contractors. MCT: PII/PHI collected, stored, and transmitted by MCT is detailed in PIA-012 and PIA-013. BEDAP: Date of Birth, Name, Zip code, Current coverage name/ ID Biometric Identifiers, E-Mail Address, Mailing Address, Phone Numbers, Medical Records Number, Medical Notes, Health Insurance Claim Number (HICN); Username, Password (encrypted as a hash)
 
Indicate the categories of individuals about whom PII is collected, maintained or shared.
  • Employees
  • Vendors/Suppliers/Contractors
  • Other - Other - PPL: Employees, Vendors/Suppliers/Contractors, Other - Public Consumers. MCT: Public Consumers-authenticated beneficiaries. BEDAP: Employees, Public Citizens, Patients, Providers, Suppliers, and Hospitals                                                 PQDC: CMS Employees and Direct Contractors                             CCXP: CMS Employees/Direct Contractors
 
How many individuals' PII in the system?100,000-999,999 
For what primary purpose is the PII used?

MCIET 

MCIET does not use login credentials for any of the products.

MCIET uses PIII to validate an individual's Identity when logging into the Medicare.gov website to compare information and make more informed decisions about their healthcare.

MCT

PII/PHI data is used for authenticated beneficiaries and by CSRs who are supporting the beneficiary in the selection of a Medicare Plan and open enrollment.

Data will be retained for 7 years in order to facilitate a relevant and personalized experience even for users who have not interacted with Medicare in some time, and to facilitate analytics that identifies long-term trends in omnichannel utilization by Medicare beneficiaries. 

BEDAP

BEDAP uses PII/PHI to facilitate a personalized experience as beneficiaries engage with and receive outreach from Medicare.

PQDC

PQDC uses PII to validate a user’s identity and authorize them.

CCXP

CCXP uses PII to validate a user’s identity and authorize them.

 
Describe the secondary uses for which the PII will be used (e.g. testing, training or research)Not applicable 
Describe the function of the SSN.

MCT: Social Security Number (SSN) is retrieved from the Beneficiary Experience Data Analytics Platform (BEDAP) or the MCT User Interface (UI) for beneficiaries applying to enroll in Dual Eligible Special Needs Plans.
If collected, SSN is included in the enrollment request which is transactionally passed to the Health Plan Management System (HPMS) OEC API for plans to download in bulk in the HPMS System. Enrollment Requests are retained in the MCT Database for 7 years.

MCT users enter PII data into the system primarily to complete enrollment forms. The Medicare.gov Privacy Policy (https://www.medicare.gov/privacy-policy) covers the disclosure, consent and uses of the enrollment form data with the rest of the medicare.gov site.
When a User Clicks “enroll” but before entering any PII the following message is displayed in accordance with CMS policy: “All information you provide here is strictly confidential and secure. We only share this information with the plan you’re joining”
Next after a user has entered or validated their MBI, but before entering any other PII/PHI, every user attests they have read and understood the contents of the following statement:
“The Centers for Medicare & Medicaid Services (CMS) collects information from Medicare plans to track beneficiary enrollment in Medicare Advantage (MA) or Prescription Drug Plans (PDP), improve care, and for the payment of Medicare benefits. Sections 1851 and 1860D-1 of the Social Security Act and 42 CFR §§ 422.50, 422.60, 423.30 and 423.32 authorize the collection of this information. CMS may use, disclose and exchange enrollment data from Medicare beneficiaries as specified in the System of Records Notice (SORN) “Medicare Advantage Prescription Drug (MARx)”, System No. 09-70-0588. Your response to this form is voluntary. However, failure to respond may affect enrollment in the plan.”

 
Cite the legal authority to use the SSN.Sections 1851 and 1860D-1 of the Social Security Act and 42 CFR §§ 422.50, 422.60, 423.30 and 423.32 authorize the collection of this information. 
Identify legal authorities​ governing information use and disclosure specific to the system and program.

Authority for maintenance of the system is given under sections 1102, 1804(b), and 1851(d) of the Social Security Act (42 United States Code (U.S.C.) 1302, 1395b–2(b), and 1395w– 21(d)), and OMB Circular A–123, Internal Control Systems, and Title 42 U.S.C. section 1395w– 21(d) (Pub. L. 105–3, the Balanced Budget Act of 1997).

The Medicare Modernization Act of 2013

5 U.S.C. Section 301 Departmental Regulations

CURES Act of 2016 Section 4011
Section 508 Compliance (Rehabilitation Act)

 
Are records on the system retrieved by one or more PII data elements?Yes 
Identify the number and title of the Privacy Act System of Records (SORN) that is being used to cover the system or identify if a SORN is being developed.1–800 Medicare Helpline (HELPLINE), SORN 09-70-0535. 
Identify the sources of PII in the system: Directly from an individual about whom the information pertains
  • In-Person
  • Online
 
Identify the sources of PII in the system: Government SourcesWithin the OPDIV 
Identify the OMB information collection approval number and expiration dateNot applicable 
Is the PII shared with other organizations?No 
Describe the process in place to notify individuals that their personal information will be collected. If no prior notice is given, explain the reason.

PPL

An individual is presented with the Medicare.gov Privacy Policy and must click a checkbox to acknowledge that they understand it.

The notification occurs at the EUA logon page, as part of the process to obtain general access to CMS systems as a CMS employee or direct contractor

MCT

MCT does not provide a separate privacy notification to users regarding personal information. Any notification would be a part of the Medicare.gov website. There is no option for consumers to opt-out of MCT collecting and storing PII, since it is necessary to complete a medicare.gov enrollment.

BEDAP

A privacy notice is provided to individuals by systems upstream of BEDAP.

CCXP and PQDC

Not applicable; users have a reasonable expectation of having their credentials collected by these systems.

 
Is the submission of the PII by individuals voluntary or mandatory?Voluntary 
Describe the method for individuals to opt-out of the collection or use of their PII. If there is no option to object to the information collection, provide a reason.There is no option for consumers to opt-out of providing PII or for the system storage of PHI, since it is necessary to register to the Medicare website to compare cost. 
Describe the process to notify and obtain consent from the individuals whose PII is in the system when major changes occur to the system (e.g., disclosure and/or data uses have changes since the notice at the time of original collection). Alternatively, describe why they cannot be notified or have their consent obtained.Since MOSS is accessible through Medicare.gov website, any changes or updates to the system would be posted on the Medicare.gov website. 
Describe the process in place to resolve an individual's concerns when they believe their PII has been inappropriately obtained, used, or disclosed, or that the PII is inaccurate. If no process exists, explain why not.Individuals who have concerns about their PII/PHI being inappropriately obtained, used or disclosed should contact the Medicare.gov call center at 1-800-633-4227. 
Describe the process in place for periodic reviews of PII contained in the system to ensure the data's integrity, availability, accuracy and relevancy. If no processes are in place, explain why not.There is not a defined process for periodic reviews of PII/PHI in MOSS because any PII/PHI is received from upstream systems rather than being collected by MOSS. The PII/PHI is transferred on a daily and weekly basis from those systems, so MOSS would inherently receive any changes pursuant to their data integrity processes – including those that ensure integrity, availability, accuracy and relevancy MOSS receives and stores PII/PHI in secured formats.
All web transactions and software functions are logged, and logs are aggregated into Splunk and stored for 1 year should any audit of the system need to take place.
 
Identify who will have access to the PII in the system and the reason why they require access.
  • Administrators: MCIET and BEDAP -The administrators have access to PII to generate a list of system users and manage and assign access to MOSS system. MCT-The System administrators have access to PII to manage the MCT database and PII access logging in Splunk. CCXP and PQDC -Admins have access to no PII except the passwords on the system for the admins.
  • Contractors: Direct contractors, in their role as an administrator, would have access to PII as described in the "Administrator’s" explanation above.
 
Describe the procedures in place to determine which system users (administrators, developers, contractors, etc.) may access PII.

MCIET, MCT, and BEDAP

Access to PII is limited to the MOSS system administrators. MOSS uses the principle of least privilege as well as a role-based access control to ensure system administrators are granted access on a "need-to-know" and "need-to-access” basis.

PQDC and CCXP

Not applicable

 
Describe the methods in place to allow those with access to PII to only access the minimum amount of information necessary to perform their job.

MCIET, MCT, BEDAP, PQDC and CCXP

MOSS uses the principle of least privilege as well as a role-based access control to ensure system administrators are granted access on a "need-to-know" and "need-to-access" commensurate with their assigned duties.

User accounts are reviewed annually or on an as needed basis when a user is terminated from the project and their access are removed.

 
Identifying training and awareness provided to personnel (system owners, managers, operators, contractors and/or program managers) using the system to make them aware of their responsibilities for protecting the information being collected and maintained.All personnel (direct contractors and CMS employees) are required to complete the annual CMS Security and Privacy Awareness training provided annually as Computer Based Training (CBT) course. Direct contractors also complete their annual corporate security training. 
Describe training system users receive (above and beyond general security and privacy awareness training)Not applicable 
Do contracts include Federal Acquisition Regulation and other appropriate clauses ensuring adherence to privacy provisions and practices?Yes 
Describe the process and guidelines in place with regard to the retention and destruction of PII. Cite specific records retention schedules.

MOSS follows the CMS Records Schedule as follows:

Enrollment Records:

Disposition Authority Number: DAA-0440-2015-0006-0001

Cutoff Instruction: Cutoff at the end of the calendar year.

Retention Period: Destroy no sooner than 7 year(s) after cutoff but longer retention is authorized.

Beneficiary Records:

Disposition Authority Number: DAA-0440-2015-0007-0001

Cutoff Instruction: Cutoff at the end of the calendar year.

Retention Period: Destroy no sooner than 10 year(s) after cutoff but longer retention is authorized.

Provider and Health Plan Records:

Disposition Authority Number: DAA-0440-2015-0008-0001

Retention Period: Destroy no sooner than 7 year(s) after cutoff but longer retention is authorized.

Analytic and Research Files (restricted)

Disposition Authority Number DAA-0440-2015-0009-0002

Transfer to the National Archives for Accessioning: Transfer to the National Archives 20 year(s) after cutoff.

Research and Program Analysis: Supporting Records

Disposition Authority Number: DAA-0440-2015-0009-0003

Cutoff Instruction: Cutoff at the end of the calendar year.

Retention Period: Destroy 10 year(s) after cutoff or when no longer needed for agency business, whichever is latest

 
Describe, briefly but with specificity, how the PII will be secured in the system using administrative, technical, and physical controls.

MCIET, BEDAP, PQDC and CCXP

The administrative controls in place to secure the PII/PHI include role-based access and permissions, periodic review of users and deletion of non-active accounts.

The technical controls in place are firewalls that prevent unauthorized access, encrypted access when privileged users log into MOSS, security scans, penetration testing and intrusion detection and prevention technologies. There is also active penetration testing and a tiered system architecture which means the testing, development and production environments are separated and only assigned users may access each one.

MCT

PII/PHI data will be encrypted in transit and at rest. Transport Layer Security (TLS) will be used in transit and with all integrated system exchanges. PII/PHI data will be encrypted at rest and segregated from non-PII/PHI data. Unnecessary PII/PHI data will not be collected or saved. Unnecessary PII/PHI data returned from upstream systems will be removed on first contact with MCT front-end.

 
Identify the publicly-available URL:

MCIET formerly PPL

https://www.medicare.gov/procedure-price-lookup/

DME/Supplier Directory

https://www.medicare.gov/medical-equipment-suppliers/ 

Location Widgets:
OTP
https://www.medicare.gov/opioid-treatment-program/results?location=2016%20Bay%20Area%20NARM%20Training%20By%20Laurence%20Heller,%201005%20Atlantic%20Ave,%20Alameda,%20CA,%2094501,%20USA

MDPP
https://www.medicare.gov/medicare-diabetes-prevention-program/results?location=20102,%20Dulles,%20VA,%20USA&radius=25

MCT

https://www.medicare.gov/plan-compare/#/ 

BEDAP

N/A

PQDC

http://data.cms.gov/provider-data/

CCXP

https://www.medicare.gov/care-compare

 
Does the website have a posted privacy notice?Yes 
Is the privacy policy available in a machine-readable format?Yes 
Does the website use web measurement and customization technology?No 
Does the website have any information or pages directed at children under the age of thirteen?No 
Does the website contain links to non-federal government website external to HHS?No