Salesforce Enterprise Integration

The SEI system will collect and store identity provisioning data for user/IDM registration. This data is received from IDM during the authentication process. Once a user is created and provisioned in the Enterprise Org and Component Org, their credentials (User ID, Password, and MFA token) will allow them to access their downstream specific Component Org application. 

The type of user information/data collected and stored includes: first name, last name, email address, phone number, mailing address, postal code, state, EUA or IDM ID, user role, user type, email, company name, profile permissions, and last modified date.

SEI collects the taxpayer ID (TIN), which is associated with a business, not an individual person only when it is necessary and the business provides it for verification purposes.

The Component Orgs collects and stores the following PHI data:

Health Care Entity: This is collected to identify providers and verify their legal name against other important identifier data.

Provider Transition Access Number (PTAN): This is collected for reference when processing settlements/cases.

CMS Certification Number (CCN): This is used to verify Medicare/Medicaid certification for survey and certification, assessment-related activities and communications.

National Provider Identifier (NPI): This is collected and used to facilitate payments or reimbursements.

The SEI system provides a set of CMS Shared Services to allow internal and external user access to CMS business unit/organization Salesforce systems also referred to as Component Orgs. In addition to SSO access services, it also provides Anti-Virus (AV) scanning and event monitoring/auditing. The primary intent of the Salesforce Enterprise Integration (SEI) system is to provide SSO access by utilizing CMS Identity Management (IDM), AV solutions, and to provide event monitoring and auditing via Splunk. 

SEI facilitates the Single Sign-On authentication for Users accessing the COs utilizing the IDM platform. SEI stores PII attributes which are passed from the IDM system via SAML assertion.

These attributes include name, phone number, email, and address and are stored in Salesforce objects as required data fields.

SEI collects the taxpayer ID (TIN), which is associated with a business, not an individual person only when it is necessary and the business provides it for verification purposes.

The Component Orgs collects and stores the following PHI data:

Health Care Entity: This is collected to identify providers and verify their legal name against other important identifier data.

Provider Transition Access Number (PTAN): This is collected for reference when processing settlements/cases.

CMS Certification Number (CCN): This is used to verify Medicare/Medicaid certification for survey and certification, assessment-related activities and communications.

National Provider Identifier (NPI): This is collected and used to facilitate payments or reimbursements.

Physical Security System personnel who access or use the system do not use any personal identifiers to retrieve records held in the system.

• Name
• Mother's Maiden Name
• E-Mail Address
• Phone Numbers
• Taxpayer ID
• Mailing Address
• Other - First name, last name, phone number, postal code, state, company name, Health Care Entity, PTAN, CCN, NPI, User Role,  EUA/IDM ID, profile permissions and last modified date (from EUA/IDM).

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

Online

Email

• Within the OPDIV
• Other Federal Entities
• Other - For the SEI SSO shared service, IDM is the source of PII in the system.

• Members of the Public
• Private Sector: No PII is shared with the private sector - PII will only be used by the applicable CMS business unit or Help Desk for assistance with system access (password resets, locked accounts, etc.).

• Users: Application End Users require access and permission rights to enter and edit data to support CMS business needs, processes, and requirements.
• Administrators: Salesforce Administrators require access and permission rights to create Salesforce Objects/Fields, Workflows, Screen, Validation rules and other configuration changes to support business needs, processes, and requirements.
• Developers: Salesforce Developers require access and permission rights to build and maintain custom applications and workflows which support business needs, processes, and requirements.
• Contractors: Direct CMS support contractors require access and permission rights to build and maintain custom applications and workflows to support business requirements and processes. Direct CMS support contractors sign CMS Non-Disclosure Agreements (NDA's).

Administrative: Users are provided with privacy training to understand how to properly handle and disclose privacy data.

Technical: role-based access has been employed by the application to ensure that users only have access to the data that is needed in the performance of the specific jobs.

Physical: Physical controls are administered by the Salesforce Data Center facility where the application will physically reside. The Salesforce facility has security guards and controlled access rooms with cipher locks to guard against unauthorized access.

• Session Cookies: Yes