CCIIO Customer Relations Management System

OPDIV:

CMS

PIA Unique Identifier:

P-5882866-285645

Name:

CCIIO Customer Relations Management 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

Identify the operator:

Contractor

Is this a new or existing system?

Existing

Does the system have Security Authorization (SA)?

Yes

Date of Security Authorization

12/13/2022

Indicate the following reason(s) for updating this PIA. Choose from the following options.

PIA Validation (PIA Refresh/Annual Review)

Describe in further detail any changes to the system that have occurred since the last PIA.

A new Federally Facilitated Marketplace Assister Community (FFM-AC) platform has been created to conduct outreach (through Assister Support) for consumers transitioning from Medicaid to Marketplace coverage. 
Independent Dispute Resolution (IDR) Entity (IDRE) Data API Exchange: An Amazon Web Service (AWS) Virtual Machine (VM) was created to run Python scripts to intake, validate and reconcile IDRE Salesforce data. 
The Center for Consumer Information and Insurance Oversight (CCIIO) Customer Relations Management System (CCRMS) received a Provisional Authority to Operate (P-ATO) on 04/03/2024 for Software-as-a-Service (SaaS) Product Adaptus EzProtect (Anti-Virus/ Anti-Malware Solution). The system already utilizes this tool, the system migrated from the Centers for Medicare & Medicaid Services (CMS) Cloud Environment fully to the Adaptus Cloud Environment. The on-prem EzProtect service has been decommissioned.  
The Premium Stabilization Program (PSP) and Marketplace Assister Technical Support (MATS) have data ‘Encrypted at Rest’ (EaR) in Amazon Web Services and ‘Encrypted in Transit’ (EIT) transit to/ from Salesforce with Secure Sockets Layer (SSL) Transport Layer Security (TLS) 1.3. 

Describe the purpose of the system

The CCRMS supports customer service efforts related to back-office functions of the Affordable Care Act (ACA) and the Marketplace. CCRMS is hosted in the Federal Risk and Authorization Management Program (FedRAMP) accredited cloud hosting environments of Salesforce NA21 Instance and AWS East/West.  CCRMS is not hosted in the CMS Enterprise Salesforce.  

Salesforce Cloud 
CCRMS is comprised of four Salesforce organizations: 

Re-Insurance Contribution System (RICS) 
 The system receives and processes inquiries from plan sponsors, tracks the inquiry progress through to resolution and response.

 The system ingests data from www.pay.gov for the remittance of Reinsurance Contributions and related discrepancies. 
 Interfaces with Pay.gov  

Risk Adjustment and Re-Insurance (RARI)/ Risk Adjustment Data Validation (RADV)/Vendor Management (VM) 
The system receives and processes inquiries from organizations that participate in the Marketplace. 
The system collects and tracks ancillary information about the companies and related External Data Gathering Environment (EDGE) Server data that participate in the Marketplace and wish to receive RARI payments; for example, baseline data, discrepancy reports, ACA financial appeals, contact data, etc. in support of various project. 
 The system brings together the processes of intaking and responding to questions, hosting a library with program information, and intaking and completing audit processes. 

MATS
The system collects and processes inquiries from Marketplace Assisters and organization that support to consumers in completion, enrollment, and eligibility assistance. 

System Plan and Issuer Data Reporting (SPIDR) 
SPIDR is a platform that provides automation to facilitate continuous process improvement to support the highly complex operations related to the design, display, certification, and management of qualified health plans. 
Collects, evaluates, and certifies Quality Health Plans (QHPs) from Issuers. 
Facilitates the collection of data from Issuers to evaluate and certify plans, including QHPs and Stand-Alone Dental Plans (SADPs). The data is collected, validated, and stored within the SPIDR system. 
Allows users to access their Issuer/Plans and Case information configured to meet the CCIIO needs for managing and reporting on Issuer and Plan Management activities. 

Within the Salesforce environment, CCRMS developers use the Salesforce Visualforce framework.  Visualforce is a framework that allows developers to build sophisticated, custom user interfaces that can be hosted natively on the Salesforce Lightning platform. The Visualforce framework includes a tag-based markup language, like HTML, and a set of server-side “standard controllers” that make basic database operations, such as queries and saves, very simple to perform.

 
The Consolidated Appropriations Act (CAA) of 2021 became Public Law No: 116-260 on December 27, 2020. Two acts within the law apply to CCIIO: Division BB, Title I, "No Surprises Act." and Title II, "Transparency. “CCIIO assessed the provisions in Titles I & II and determined that it needed to: 
Develop policy to further define the details of the provision 
Implement operational processes and technical functionality to support operations of the provisions 
Coordinate across CMS (e.g., with ASPE) and with Department of Labor, Department of Treasury, and Department of Transportation according to the legislation. 

From those provisions, seven workstreams were identified that required CCIIO to build new or modify existing system functionality. Of these seven, the IDR and Complaints workstreams were added to MATS.  

Independent Dispute Resolution 
The IDR establishes an independent pathway for issuers, providers, and consumers to settle payment disputes, providing information on payment practices to inform future policymaking, establish an effective IDRE certification process that ensures IDR parties have easy access to qualified and carefully evaluated federal IDREs to help successfully resolve their IDR case.  The IDR is comprised of the following:

IDRE Application- landing page and application web form for an entity to apply to become a certified IDRE 
IDRE Registration - if application approved, the applicant would receive an invitation to the IDR Entity Community  
IDRE Community- this is an environment where IDREs can renew, re-certify, and/or withdraw their IDRE certification, update their organization/identifying information  IDRE Certification Process- is a multi-step process using Salesforce to review, evaluate and retain the application data submitted; the review process will help indicate whether the candidate should be eligible to become a certified IDRE. If the application is reviewed and approved to be eligible for certification, there will be a public forum for a petitioning period.  

Complaints 
Complaints is an established process to receive issuer and provider complaints of violations of No Surprise Act rules, including non-compliance with out-of-network service billing (payer is billed by provider and doesn't think they should be), and non-payment by payer to provider (provider submits complaint against payer). The Complaints system is comprised of: 
Establishing and publicizing a system solution capable of efficiently receiving, ticketing, triaging, and tracking cases from consumers related to plan, issuer, and/or provider non-compliance with surprise billing provisions 
Providing responses to such complaints within 60-days of receipt 
Increasing efficiency of working cases and decrease resolution time of open cases through collaboration functionality. 
Improve other workstreams: i.e., system data can be analyzed and interpreted to determine helpful language for consumer documentation.

AWS
RADV, EZ-Protect (anti-virus solution) for Salesforce file attachments, and Microlearning courseware files are maintained in the AWS environment.  CCRMS utilizes the AWS services of: CloudWatch, CloudTrail, Config, Cost Explorer, Data Transfer, DynamoDB, Elastic Compute Cloud, Elastic Load-balancing, GuardDuty, Key Management Service, Kinesis Firehose, Lambda, Relational Database Service, Secrets Manager, Security Hub, Simple Notification Service, Simple Queue Service, Simple Storage Service (s3), Workspaces and Web Application Firewall. 

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)

CCRMS collects, maintains, and stores information at multiple levels:  

Pertaining to individual and company names, email addresses, phone numbers, mailing addresses, taxpayer identification numbers, date of birth, medical record number, medical notes, financial account information and social security numbers. 

User ID, Enrollment accounts, payment information, Issuer EDGE enrollment and claim data (this is not maintained at the enrollee level).

Department of Health and Human Services (HHS) RADV Sampling Reports limited individual enrollee claim and medical record data.  
PSP data is stored back to the system inception, which is nine (9) years. Salesforce credentials are used for some users – usernames are stored, and passwords are not stored as plain text. Usernames for the PSP are established by the System Administrator based on the user's email address. When users register, they create their own password.
MATS data goes back to the system inception, which is eight (8) years, and the SPIDR has five (5) years of data stored. Salesforce credentials for MATS/ SPIDR are stored for active and inactive users. Usernames are stored, passwords are not stored as plain text. All users in Production go through the Identity Management (IDM) process to log in to Salesforce. For which individuals register with a username/ password for IDM. Users don’t use salesforce username or password to login to Salesforce. However, Salesforce creates a user record for the user and stores the information inside of salesforce.

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

The CCRMS supports customer service efforts related to back-office functions of the ACA and the Marketplace. CCRMS is hosted in the FedRAMP accredited multitenant cloud hosting environments of Salesforce NA21 Instance (Salesforce Enterprise Integration (SEI)) and consumes services from AWS GovCloud and AWS Commercial. CCRMS is not hosted in the Center for Medicare and Medicaid Innovation Cloud Service Provider Salesforce (CMMI CSP SF). 

CCRMS is comprised of the following Salesforce SaaS: 

RICS: The system receives and processes inquiries from plan sponsors, tracks the inquiry progress through to resolution and response. It ingests data from www.pay.gov for the remittance of Reinsurance Contributions and related discrepancies. 

RARI/ RADV/VM: The system receives and processes inquiries from organizations that participate in the Marketplace. It brings together the processes of intaking and responding to questions, hosting a library with program information, and intaking and completing audit processes. 

MATS: The system collects and processes inquiries from Marketplace Assisters and organization that support to consumers in completion, enrollment, and eligibility assistance. 

SPIDR: SPIDR is a platform that provides automation to facilitate continuous process improvement to support the highly complex operations related to the design, display, certification, and management of qualified health plans. It collects, evaluates, and certifies QHPs from Issuers; and allows users to access their Issuer/Plans and Case information configured to meet the CCIIO needs for managing and reporting on Issuer and Plan Management activities. 

IDR: The IDR establishes an independent pathway for issuers, providers, and consumers to settle payment disputes, providing information on payment practices to inform future policymaking, establish an effective IDRE certification process that ensures IDR parties have easy access to qualified and carefully evaluated federal IDREs to help successfully resolve their IDR case. 

Complaints: Complaints is an established process to receive issuer and provider complaints of violations of No Surprise Act rules, including non-compliance with out-of-network service billing (payer is billed by provider and doesn't think they should be), and non-payment by payer to provider (provider submits complaint against payer). 

The information provided will be stored permanently and will not be shared with organizations outside of the agency, except for social security number, which are stored temporarily and sent to external partners. As a result, the Personal Identifiable Information (PII) that is collected to retrieve system records includes first/ last name, email address, social security number, phone number, medical notes, taxpayer id, date of birth, mailing address, medical records number, financial account number, userid, enrollment accounts, payment information, and claim data. The users authorized to have access are employees, public citizens, patients and Federal, State and Local Agencies. 

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

• Medical Notes

• Taxpayer ID

• Date of Birth

• Mailing Address

• Medical Records Number

• Financial Account Info

• Other - User ID, enrollment accounts, payment information, and Issuer EDGE enrollment and claim data

Indicate the categories of individuals about whom PII is collected, maintained or shared.

• Employees

• Public Citizens

• Business Partners/Contacts (Federal, state, local agencies)

• Vendors/Suppliers/Contractors

• Patients

How many individuals' PII in the system?

1,000,000 or more

For what primary purpose is the PII used?

The PII purposes:

User identification, validation, and authorization (name, email, and phone number). The information is needed to create user accounts as well as complete any help desk service request that is initiated by the individual.  

RADV audit. PII for individuals is collected by the system for individuals enrolled in the medical plans covered by the Marketplace.  The information is needed to audit the accuracy of the information on the EDGE servers.

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

N/A

Describe the function of the SSN.

Social Security number (SSN) is received as part of consumer data and sent downstream to external partners. SSN are not permanently stored within Salesforce, they are temporarily stored. 

Cite the legal authority to use the SSN.

Sections 1411 and 1414 of the ACA

Identify legal authorities​ governing information use and disclosure specific to the system and program.

5 U.S.C. § 552a(e)(3)
Sections 9816(c) and 9817(b) of the Internal Revenue Code
Sections 716(c), 717(b) of the Employee Retirement Income Security Act of 1974 (ERISA)
Sections 2799A-1(c), 2799A-2(b), 2799B-4(b)(3), 2799B-1, 2799B-2, 2799B-3, 2799B-5, 2799B-7, 2719, 2723, and 2761 of the Public Health Service (PHS) Act
Section 1321(c) of the Affordable Care Act.
CAA of 2021 became Public Law No: 116-260 on December 27, 2020. Two acts within the law apply to CCIIO: Title I, "No Surprises Act." and Title II, "Transparency 

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.

09-70-0560 Health Insurance Exchanges (HIX) Program 

09-70-0516 Complaints Against Health Insurance Issuers and Health Plans (CAHII) 

09-70-0511 CMS Risk Adjustment Data Validation System (RAD-V) 

Identify the sources of PII in the system: Directly from an individual about whom the information pertains

Online

Identify the sources of PII in the system: Government Sources

Within the OPDIV

Identify the sources of PII in the system: Non-Government Sources

• Members of the Public

• Public Sector

Identify the OMB information collection approval number and expiration date

OMB collection approval number 0938-1187 - expiration date 06/30/2025 

Is the PII shared with other organizations?

Yes

Identify with whom the PII is shared or disclosed and for what purpose.

Within HHS: The company or plan information is used to validate CCRMS users to obtain a log in to the system.  The enrollee level details are used to validate the necessary HHS RADV audits of Issuers.

Describe any agreements in place that authorizes the information sharing or disclosure (e.g. Computer Matching Agreement, Memorandum of Understanding (MOU), or Information Sharing Agreement (ISA)).

Data Use Agreements (DUA’s): 

MATS/SPIDR DUA CONT-2021-56912
Payment Policy and Financial Management Group (PPFMG) Premium Stabilization Programs and Marketplace Operational Support DUA CONT 2014-27183

Describe the procedures for accounting for disclosures

The CCRMS follows the CMS/ HHS Vulnerability Disclosure Policy, as well as the CMS.gov Privacy Policy. 

Disclosure Statement: “HHS is committed to timely correction of vulnerabilities. However, we recognize that public disclosure of a vulnerability in absence of a readily available corrective action likely increases versus decreases risk. Accordingly, we require that you refrain from sharing information about discovered vulnerabilities for 90 calendar days after you have received our acknowledgement of receipt of your report. If you believe others should be informed of the vulnerability prior to our implementation of corrective actions, we require that you coordinate in advance with us. 

We may share vulnerability reports with the Cybersecurity and Infrastructure Security Agency (CISA), as well as any affected vendors. We will not share names or contact data of security researchers unless given explicit permission.” 

For more details, reference the Vulnerability Disclosure Policy | HHS.gov 

Privacy Policy: Protecting your information is very important to us. This privacy policy describes what information we collect, why we collect it, and what we do with it, available at Privacy Policy | CMS. 

Describe the process in place to notify individuals that their personal information will be collected. If no prior notice is given, explain the reason.

No prior notification is required.  PII data that is collected is through the plan sponsors or organizations who participate in the Federally Funded Marketplace.

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 "opt out" feature required.  The information is required for identification, validations, and authorization by the individual to complete the help desk transaction. 

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.

CCRMS sub systems contain privacy statements on each of the forms completed by the plan sponsor or organization.  Normally, no further notifications are required once the user completes the form validation and verification process.  A user would be notified via email of major system changes. 

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.

The individual may contact the specific work stream Help Desk directly by email.  This process initiates a ticket number by which a Help Desk agent will respond appropriately to the contact information the user provided. 

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.

The CCIIO Customer Relations Management Team conducts reviews of any discrepancies reported by either automated auditing controls, user submitted discrepancies, or manual auditing.  Any variation in the accuracy or integrity of the information is logged and reported to CCIIO leadership with details of the audit and additional actions taken for remediation. 

Identify who will have access to the PII in the system and the reason why they require access.

• Administrators: Authorized users such as administrators are provided with a minimum necessary system access for each module for the performance of required tasks. Administrators do not regularly access. Discretionary security controls and audit controls are in place.

• Developers: Developers are provided with a minimum necessary system access. Developers do not regularly access PII but only as necessary to perform tasks. Discretionary security controls and audit controls are in place.

• Contractors: Direct contractors are responsible for maintaining and supporting CCRMS and are required to view PII data to support Help Desk Services.

• Others - Business Analysts and Testers: Business Analysts and Testers are provided with a minimum necessary system access. Developers do not regularly access PII but only as necessary to perform tasks. Assister organization leadership also have access to consumer PII when they are logged into the Marketplace Assister Community (MAC).  Discretionary security controls and audit controls are in place.

Describe the procedures in place to determine which system users (administrators, developers, contractors, etc.) may access PII.

The administrative procedures in place to determine which system users may access PII are authentication and authorization rules that give specific permissions to each user role. Role-based access is based on the principle of 'least privilege' where users are given 'need to know' and 'need to access' permissions. All user roles and authorizations for the system are documented in the CCRMS System Security and Privacy Plan (SSPP). Acquiring PII within Salesforce requires individuals to access either CMS IDM or username/password with two factor authentication enabled.  

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.

The system controls in place for access to PII include role-based access permissions, and limits on the PII that is displayed so that only the minimum amount of PII is visible to users. Users are assigned different roles corresponding to different levels of access to data as well as the ability to perform specific actions (e.g., read, update, delete). 

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 CCRMS personnel undergo corporate and project-specific training at time of hire and annually thereafter. This training includes the CMS Information Systems Security and Privacy Awareness (ISSPA) course (mandatory for all users of CMS Information Systems when users are initially issued their CMS User ID) and review/ signature of the HHS Rules of Behavior, with content specific to the protection of PII.  

CCRMS personnel must also complete project-specific training before starting work on the project or receiving access to additional roles within CCRMS. 

Describe training system users receive (above and beyond general security and privacy awareness training)

CCRMS personnel are to complete role-based training on at least an annual basis. Training courses are provided by the agency or contractor and include content about updates to the Cloud Service Providers (Amazon Web Services, Salesforce), policy and procedure updates, and proper use of the information system. 

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.

CCRMS operates in accordance with the CMS CCIIO Records Retention Schedule File Plan, National Records Association (NARA), and General Records Schedule (GRS) 3.2 (N1-GRS-07-3 item 13a2). 

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

PII is secured in the system using administrative, technical, and physical controls, in accordance with policies and regulations detailed in the CMS Information Security Acceptable Risk Safeguards-Minimum Security Requirements (ARS).  

Administrative controls include role-based permissions to access CCRMS web pages and applications, request and authentication through the CMS IDM system, security and network policies and procedures as well as security and privacy training regarding securing PII. 

Technical controls include role-based access, inactivity timeout, multi-factor authentication, data encrypted at rest, data encrypted while being transmitted electronically, network firewall, anti-virus/malware prevention, intrusion detection/ prevention technologies, centralized event log monitoring and event alerts.  

CCRMS, being hosted in the cloud inherit physical security controls from the FedRAMP Salesforce Government Cloud and Amazon Web Services GovCloud and Commercial. 

Identify the publicly-available URL:

https://nsa-idr.cms.gov/billdisputes

https://nsa-idr.cms.gov/providerresponse

https://nsa-idr.cms.gov/idreapplication

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?

Yes

Select the type of website measurement and customization technologies is in use and if is used to collect PII. (Select all that apply)

Session Cookies

Web Beacons - Collects PII?:

No

Web Bugs - Collects PII?:

No

Session Cookies - Collects PII?:

No

Persistent Cookies - Collects PII?:

No

Other - Collects PII?:

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