CCSQ Data Repository and Analytics Platform
Privacy Impact Assessment (PIA) published by CMS as an Operating Division of the U.S. Department of Health and Human Services
Date signed: 12/5/2023
OPDIV: | CMS | ||
|---|---|---|---|
PIA Unique Identifier: | P-3503590-335823 | ||
Name: | CCSQ Data Repository and Analytics Platform | ||
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: | Agency | ||
Is this a new or existing system? | Existing | ||
Does the system have Security Authorization (SA)? | Yes | ||
Date of Security Authorization | 1/10/2025 | ||
Indicate the following reason(s) for updating this PIA. Choose from the following options. |
| ||
Describe in further detail any changes to the system that have occurred since the last PIA. | -CDRAP SIA Databricks Release: The transition from the Ambari/Hadoop-based system to the new platform, either EMR Studio + EMR or Databricks Notebooks + DB Compute, has been successfully completed. Users now enjoy a more stable and scalable environment for coding in Python, PySpark, and R, with isolated compute environments for their analyses. The new setup has significantly improved productivity by reducing resource contention, minimizing maintenance disruptions, and simplifying user access to essential coding and data resources. Data sharing capabilities have been enhanced, allowing users to collaborate more effectively and efficiently. Change Type:
Impacted Security Documentation:
-FSX Lustre: The previously approved SIA was updated to implement AWS Amazon FSx (Lustre) as a replacement for the Storage Gateway. This change provides an NFS path to S3 object stores and maintains the same mechanisms via the AWS console. Existing S3 buckets are now registered with the Lustre FSx endpoint, and user access is controlled through Data Access Groups (DAG). Data encryption is managed by AWS, ensuring security for data at rest and in transit. Logging and access control remain unchanged, and no new PII/PHI has been introduced. The Technical Direction Board approved the update, and it was released in the ADO10 environment on 04/24/2023. Change Type:
Impacted Security Documentation:
-Managed Workflows for Apache Airflow (MWAA): We successfully transitioned to Amazon MWAA, a managed service that simplifies running Apache Airflow, enabling automated data refresh processes. This move has reduced the burden on teams, ensured consistency, and maintained security by leveraging AWS for stability and compliance, eliminating the need to manage Airflow servers. Key changes included implementing MWAA to schedule automated data workflows, utilizing existing AWS technologies like EMR clusters, migrating from Airflow 1.x to MWAA with Airflow 2.x, and hosting on ADO10-DA-Prod. We also established appropriate IAM roles for accessing EMR clusters and S3 buckets. This transition has enhanced system stability, reduced maintenance efforts, and ensured the latest Airflow versions are used, all while maintaining the existing processes for handling PHI/PII data securely. Change Type:
Impacted Security Documentation:
-PayloadCMS (Pre-Prod): To easily display content and enable non-programmers to manage and create content, particularly for training and integration documentation for the CDR, we successfully implemented PayloadCMS as our headless content management system (CMS). After encountering compatibility issues with the ESS H-CMS solution and licensing issues with Directus.io, we selected PayloadCMS as the most viable solution to meet our needs. PayloadCMS, a Node.js application, was hosted in a containerized pre-production environment within F5 on Kubernetes, requiring a new Postgres database in our existing RDS instance. Content is now managed via the PayloadCMS front-end by authorized content creators, approvers, and administrators, while the portal consumes the content via RESTful API. End users do not directly interact with the CMS front-end or the content itself. Access to PayloadCMS requires a HARP account, and various HARP roles moderate access for the portal. This release piloted PayloadCMS in a pre-production environment, marking the first implementation of a headless content management system for the portal. Prior to this, the portal did not have a headless content management system. Change Type:
Impacted Security Documentation:
-PayloadCMS (Prod): To conveniently display content and enable non-programmers to manage and create content, particularly for training and integration documentation for the CDR, we successfully implemented PayloadCMS as our headless content management system (CMS). After identifying compatibility issues with the ESS H-CMS solution and licensing issues with Directus.io, we selected PayloadCMS as the most viable solution to meet our needs. PayloadCMS is designed for publicly available content and non-sensitive training materials. Content is stored in a standalone Postgres database within our current RDS instance and managed through the PayloadCMS front-end by authorized content creators, approvers, and administrators. The portal consumes the content via RESTful API, ensuring end users do not directly interact with the PayloadCMS front-end or the content itself. PayloadCMS, a Node.js application, is hosted in a containerized production environment within F5 on Kubernetes. Access to PayloadCMS requires a HARP account, moderated by various HARP roles created for the portal. The user collection within PayloadCMS allows administrators to manage users with full access to all content and functionality, including creating new users, changing passwords, deleting users, and unlocking accounts. Admins are internal users, primarily the User Service team for content management and the Portal team for support. This production release of PayloadCMS marks the first implementation of a headless content management system for the portal. Change Type:
Impacted Security Documentation:
-SAS EBI Cloud Provider: To support end users in completing their contractual deliverables requiring data from the IDR, which was not available in the CDR, we successfully implemented a change for SASEBI users. These users needed to consume both IDR and CDR data for analytics. Previously, SASEBI could not access CDR data. To address this, we created an IAM role to grant access to the data consumer working storage location in the CDR Lakehouse for ESRD-QIP-Arbor and HQR-Bellese. The SAS EBI tool now assumes this IAM role, allowing the SAS EBI Cloud Platform (FISMA Name: SASEBICP) to connect to user data in ADO10-DAL. This new approach replaced the existing DEP/FINDER process where users logged into SAS EBI, produced deliverables from IDR data, transferred files to the mainframe, and then EFT transferred files to the CDR Landing Zone. The updated process enables direct data transfer between SAS EBI and the CDR Lakehouse S3 bucket. This bi-directional connection is contained within the CMS AWS system's security boundary, inheriting the confidentiality mechanisms for information in transit. By adding an IAM role to access an S3 bucket within the CDRAP System Security Boundary, we ensured secure information sharing for data analytics. Amazon S3 uses Server-Side Encryption with AES-256 encryption protocol by default, protecting the confidentiality of data at rest and in transit. This change ensured that PII and PHI remained secure, leveraging AWS’s robust security measures to maintain data integrity and confidentiality. Change Type:
Impacted Security Documentation:
-Push Button SAS CI/CD Pipeline - Prod: The Push Button SAS CI/CD Pipeline automates the installation and configuration of SAS software with a single click. This solution addresses performance issues and single points of failure (SPOFs) by implementing high availability (HA) for recommended services, ensuring 99.99% uptime. Infrastructure and configurations are automated through Infrastructure as Code (IaC) and Configuration as Code (CaC), with pipelines managed by GitHub Actions. The Push Button SAS CI/CD Pipeline has been implemented to enhance performance and eliminate SPOFs in the current SAS environment. It replaces the legacy SAS PROD environment with a new setup that includes automated infrastructure, HA services, and fine-tuned performance configurations. The new environment consolidates workbenches into a single S3 bucket and upgrades the host OS from RHEL7 to RHEL8, complying with the CMS mandate. The new SAS environment includes additional servers: 2 SPRE, 3 Shared Services, 3 Database, 2 Controllers, 2 Proxy, 9+ Worker Nodes, and 1 Management server, as recommended by SAS Technical Support. There is no new PHI/PII introduced with this change. This change will proceed after successful testing of the new SAS IMPL environment created with the Push Button SAS CI/CD Pipeline. If testing is successful, the existing SAS PROD will be replaced, and data validations, regression tests, and UAT tests will be conducted and documented. If testing results are not optimal, the existing SAS PROD environment will remain unchanged. The change also involves migrating the application from RHEL7 to RHEL8 to meet CMS requirements. Vulnerability scans was provided 3/29/2024 as instructed by the ISSO. Approval from the Technical Direction Board has been granted, but the Security Impact Analysis (SIA) has not yet been approved. The "push-button" deployment method does not require an SIA, only the changes introduced alongside it. Change Type:
Impacted Security Documentation:
-MCBS - Data Pipeline SIA (PROD): To make the new MCBS data set avvailable through the data pipeline for CDR. Data is defined here: https://www.cms.gov/data-research/research/medicare-current-beneficiary-survey/data-documentation-codebooks CCW delivers data to us via an S3 bucket. We unzip it and then MWAA Airflow, then Databricks Jobs will handle the load process into the CDR. Great Expectations is used for data quality and integrity checks before data is added to the data lake. Introducing a new data pipeline required to support the new data set to be ingested in the CDR. Change Type:
Impacted Security Documentation:
| ||
Describe the purpose of the system | CDRAP: The Center for Clinical Standards and Quality (CCSQ) Data Repository and Analytics Platform (CDRAP) supports the Healthcare Quality Information System (HCQIS) Data & Modernization Project’s requirement to establish a cloud-based centralized data repository (CDR) in the HCQIS cloud environment and internet-facing multi-tool analytic solution, CCSQ Analytic Platform (CAP), for CCSQ users using the SAS Viya analytic tool. The CDR provides convenient, secure, and more timely access to CCSQ Quality data and commonly used datasets sourced from CMS systems of record. CAP (SAS Viya) functionality includes data wrangling, data visualization, basic statistics, and advanced modeling capabilities. FAS: After CMS research regulations and determines the need to propose a new regulation, a draft regulation is provided to the public. During the Public comment phase of the process, CMS accepts public comments via Regulations.gov. After the comment period closes, CMS reviews all comments and conducts a comment analysis. The Feedback Analysis System (FAS) is an internet-facing solution that receives comment data from Regulations.gov and automates the comment review process with machine learning and natural language processing. STAR: Strategy for Analytics & Reporting (STAR) is tasked with developing a set of best-practices, standards, and reusable software components that should be applied/utilized within Center for Clinical Standards and Quality (CCSQ) lines of business (LOBs) in order to ensure that their future efforts are aligned with the "One CCSQ" vision. This includes a scalable, iterative, and incremental process for collaboration among LOBs through a centralized CCSQ Amazon Web Services (AWS) Redshift data warehouse instance that also has access to all centralized data repository (CDR) data sources. | ||
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) | CDRAP: CCSQ Data Repository and Analytics Platform (CDRAP) does not collect new data. CDRAP uses copied datasets from existing data analytics systems. A copy of the original data for all types of PII/PHI that exist in consuming LoBs (Line of Business). The copied data is kept within CDRAP and can be dropped when it is no longer needed. FAS: FAS collects and stores public comment data from Regulations.gov, and Nursing Home Survey data from Statement of Deficiencies (SOD2567) forms. Both data sources do not contain any PII. In addition to the comment data and survey data, FAS stores end-user login IDs and email address of CMS employees and FAS contractors as a log entry from a CMS authentication system, HARP (Health Care Quality Information Systems (HCQIS) Access Roles and Profile). FAS provides their users the ability to share analyses and dashboards. These analyses and dashboards are stored and maintained by FAS and do not contain any PII. STAR: STAR does not collect any data but integrates with CDRAP for its data sources. STAR provides its users the ability to create and share analyses and dashboards through AWS QuickSight. These analyses and dashboards are stored and maintained by STAR. | ||
Provide an overview of the system and describe the information it will collect, maintain (store), or share, either permanently or temporarily. | CDRAP: CDRAP is a cloud-based centralized data repository and internet-facing multi-tool analytic solution that provides timely access to CCSQ quality data and commonly used datasets such as Claims (Part A, Part B, Part D), Complete Statistical Analytic Table (CSAT), beneficiary, provider data used by the QIO (Quality Improvement Organizations) Program. So, the CDR contains copies of the original data for all types of PII/PHI that exist in consuming CCSQ Lines of Business and the PII/PHI is regularly used in analysis of quality data to improve patient outcomes. CDRAP does not collect new data; it uses copies of existing datasets from existing QNET (Quality Net Exchange) systems. The data is kept within CDR for as long as needed. Since the data is not the system of record, the data can be dropped if it is no longer needed. FAS: FAS stores public comment data from Regulations.gov and Nursing Home Survey data from Statement of Deficiencies (SOD2567) forms. Data is loaded into the FAS application for processing and FAS creates data insights concerning the public comments and Nursing Home Survey data. The data is displayed in a web-based application with reports and dashboards. Both data sources do not contain any PII. STAR: The STAR system is comprised of non-prod and production environments (Dev, Test, and Production) which each reside in their own dedicated VPCs within the HCQIS AWS Cloud. Each environment is comprised of shared resources (across all environments) that reside in the Infrastructure Services VPC’s in HCQIS AWS cloud and is broken into presentation, application, and data zones/subnets. STAR does not collect any data but integrates with CDRAP for its data sources. STAR provides its users the ability to create and share analyses and dashboards through AWS QuickSight. These analyses and dashboards are stored and maintained by STAR. | ||
Does the system collect, maintain, use or share PII? | Yes | ||
Indicate the type of PII that the system will collect or maintain. |
| ||
Indicate the categories of individuals about whom PII is collected, maintained or shared. |
| ||
How many individuals' PII in the system? | 1,000,000 or more | ||
For what primary purpose is the PII used? | CDRAP: The primary purpose is to analyze quality data to improve patient outcomes. FAS: Not Applicable, no PII/PHI. STAR: The PII is used for analytics and reporting, and maps directly to each organizations' data. | ||
Describe the secondary uses for which the PII will be used (e.g. testing, training or research) | CDRAP: There are no secondary uses for PII data. FAS: Not Applicable, no PII/PHI. STAR: Secondary uses are dependent on each respective organization, to support their goals. | ||
Describe the function of the SSN. | CDRAP: The primary purpose of the social security number is to be a unique record identifier for all datasets within CDRAP. FAS: Not Applicable, no PII/PHI. STAR: Not Applicable | ||
Cite the legal authority to use the SSN. | CDRAP: Executive order 9397 and Sections 226A, 1875 and 1881 of the Social Security Act; Title 42 U.S.C., section 426-1 1395II and 1395rr FAS: Not Applicable STAR: The system does not collect or use Social Security Numbers. | ||
Identify legal authorities governing information use and disclosure specific to the system and program. | CDRAP: The statutory authority for this system is given under the provisions of Sections 226A, 1875, and 1881 of the Social Security Act (the Act) (Title 42 United States Code (U.S.C.), sections 426-1, 1395ll, and 1395rr):
Covered by the Code of Federal Regulations (CFR), Title 42 - Public Health, Chapter IV - Centers for Medicare & Medicaid Services DHHS, Subchapter F - Quality Improvement Organizations, PART 480 - Acquisition, Protection, and Disclosure of Quality Improvement Organization Information under the authority of Title 42 U.S.C. sections 1302 and 1395hh. [QIO Regulations 42 CFR PART 480]:
STAR:
| ||
Are records on the system retrieved by one or more PII data elements? | No | ||
Identify the sources of PII in the system |
| ||
Identify the OMB information collection approval number and expiration date | CDRAP/STAR: No OMB information collection approval is needed because PII is not collected directly from the individual about whom the information contains. FAS: Not Applicable | ||
Is the PII shared with other organizations? | Yes | ||
Identify with whom the PII is shared or disclosed and for what purpose. |
| ||
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)). | CDRAP: The DUAs for all organizations with whom information is shared or disclosed is maintained by QualityNet Contract Services, via the DUA Tracking confluence page. This page is updated frequently to reflect the current status of said agreements. FAS: Not Applicable STAR: Not Applicable | ||
Describe the procedures for accounting for disclosures | CDRAP: The date, nature and purpose of data sharing and disclosures is described in detail within the DUAs that are maintained by QualityNet Contract Services, via the DUA Tracking confluence page. FAS: Not Applicable, no PII/PHI. STAR: Not Applicable | ||
Describe the process in place to notify individuals that their personal information will be collected. If no prior notice is given, explain the reason. | CDRAP: CDRAP is not a source system that collects information directly from any individuals that have PII within the system. Due to this, CDRAP has no required process to notify individuals that their personal information will be collected and stored within the system. Individual notification for the collection or use of PII is handled by other CMS FISMA systems that are covered under their own existing PIAs. These systems include the Integrated Data Repository (IDR), the ESRD Quality Reporting System (EQRS), Hospital Quality Reporting (HQR), Quality Payment Program (QPP) with integration of additional datasets also planned for the future. FAS: Not Applicable, no PII/PHI. STAR: STAR does not collect personal information from individuals. | ||
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. | CDRAP: CDRAP is not a source system that collects information directly from any individuals that have PII within the system. Due to this, CDRAP has no required process for handling individual opt-out for the collection or use of PII. Individual opt-out of the collection or use of PII is handled by other CMS FISMA systems that are covered under their own existing PIAs. These systems include the Integrated Data Repository (IDR), the ESRD Quality Reporting System (EQRS), Hospital Quality Reporting (HQR), Quality Payment Program (QPP) with integration of additional datasets also planned for the future. FAS: Not Applicable, no PII/PHI. STAR: STAR is not a source system that collects information directly from any individuals that have PII within the system. All PHI/PII in STAR is a copy of data from other LOB systems covered by a SORN. | ||
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. | CDRAP: CDRAP is not a source system that collects information directly from any individuals that have PII within the system. Due to this, CDRAP has no required process for handling individual opt-out for the collection or use of PII. Individual opt-out of the collection or use of PII is handled by other CMS FISMA systems that are covered under their own existing PIAs. These systems include the Integrated Data Repository (IDR), the ESRD Quality Reporting System (EQRS), Hospital Quality Reporting (HQR), Quality Payment Program (QPP) with integration of additional datasets also planned for the future. FAS: Not Applicable, no PII/PHI. STAR: All PHI/PII in STAR is a copy of data from other LOB systems covered by a SORN | ||
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. | CDRAP: Individuals with concerns about PII collection and disclosure should follow the QualityNet Incident Response Procedures and contact the QualityNet Service Desk The QualityNet Service Desk will Generate Security Incident Tickets and assign them to the QualityNet Security Team SecurityOperationsCenter@hcqis.org. QualityNet Service Desk 866-288-8912 qnetsupport@hcqis.org The QualityNet Service Desk will Generate Security Incident Tickets and assign them to the QualityNet Security Team SecurityOperationsCenter@hcqis.org. FAS: Not Applicable, no PII/PHI. STAR: Concerns around an individual's PII are fielded by the QualityNet Help Desk. 866-288-8912 qnetsupport@hcqis.org Note that because STAR uses CDRAP as the data source, most changes to data should be made there or the LOB. | ||
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. |
CDRAP: Data within CDRAP is static once it is loaded into the system and used for analysis purposes only. Data is routinely refreshed from its various sources and goes through integrity checks prior to loading into the system to ensure the data is in the proper format and has not been tampered with. FAS: Not Applicable, no PII/PHI. STAR: STAR periodically reviews resources that are made available to all authenticated QuickSight users. In addition, STAR monitors usage of resources so that any unused resources can be reviewed by the owner organization before being purged. STAR does not review relevancy, but relies on the PII owner organization to determine this. | ||
Identify who will have access to the PII in the system and the reason why they require access. |
| ||
Describe the procedures in place to determine which system users (administrators, developers, contractors, etc.) may access PII. | CDRAP: CDRAP is located in the CMS ATO FedRAMP approved HCQIS Cloud Environment. Physical access to the data center is limited to data center administrators only (e.g. AWS personnel). CDRAP applies the principle of least privilege as well as role-based method of granting rights. All users are assigned a role and each role’s rights are restricted to only data and server resources needed to perform their job. All Production access to data requires a CMS approved Data Use Agreement, as well CMS approval. FAS: Not Applicable, no PII/PHI. STAR: STAR administrators are able to access system resources through the HCQIS network. Administrative permissions include the ability to access PII. | ||
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. | CDRAP: CDRAP applies the principle of least privilege as well as role-based method of granting rights. All users are assigned a role and each role’s rights are restricted to only data and server resources needed to perform their job.
FAS: Not Applicable, no PII/PHI.
STAR: STAR is integrated with HARP and divides each shared structure into organizations and roles. A Security Official is designated for each organization to approve access to a particular role within an org. This enforces "need-to-know" and "least privilege." | ||
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. | CDRAP/FAS/STAR: All system and site administrator users are required to take an online Security Awareness Training and Identifying and Safeguarding Personally Identifiable Information Computer based training before they are granted user credentials. This training is required to be renewed annually for all existing users. All users are trained to perform the duties necessary to work within the system to perform their specific job functions. Personnel with Security Significant Responsibility (SSR) such as developers, infrastructure/system administrators, database administrators, architects, security engineers, etc. also complete CMS Agency Role-Based Training (RBT) requirements on an annual basis, corresponding to the user’s National Institute of Standards and Technology (NIST) National Initiative for Cybersecurity Education NICE role. Any new Application Development Organizational (ADO) users or existing ADO users with a new role complete RBST requirement within 60 days of beginning their new role. | ||
Describe training system users receive (above and beyond general security and privacy awareness training) | CDRAP/FAS/STAR: Personnel with Security Significant Responsibility (SSR) such as developers, infrastructure/system administrators, database administrators, architects, security engineers, etc. also complete CMS Agency Role-Based Training (RBT) requirements on an annual basis, corresponding to the user’s NIST National Initiative for Cybersecurity Education NICE role. Any new Application Development Organizational (ADO) users or existing ADO users with a new role complete RBST requirement within 60 days of beginning their new role. | ||
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. | CDRAP: The QualityNet Media Protection and Decommission Procedures provides the guidance on how to protect media through proper access controls, media marking, media transportation, proper media sanitization techniques, and controls for sanitization and disposal decisions considering the security categorization of the associated system’s confidentiality. Data is stored and destroyed following the CMS Records schedule which follows NARA General Record Schedules (GRS). Per Disposition Authority: N1-440-09-3, Temporary. Cutoff annually. Delete/destroy when 10 years old, or when no longer needed for Agency business, whichever is later. FAS: Not Applicable, no PII/PHI. STAR: STAR periodically reviews resources that are made available to all authenticated QuickSight users. In addition, STAR monitors usage of resources so that any unused resources can be reviewed by the owner organization before being purged. STAR does not review relevancy, but relies on the PII owner organization to determine this. | ||
Describe, briefly but with specificity, how the PII will be secured in the system using administrative, technical, and physical controls. | CDRAP: PII is secured with a variety of security controls as required by FISMA and the CMS Security Program. Operational controls include but are not limited to: contingency plans and annual testing, backups of all files, off site storage of backup files, physical security including secure buildings with access cards for entry, secure data center requiring additional access permissions for entry, security guards, background checks for all personnel, incident response procedures for timely response to security and privacy incidents, initial security training with refresher courses annually, and annual role based security training for personnel with assigned security roles and responsibilities. Technical controls include but are not limited to user authentication with least privilege authorization, fire walls, Intrusion Detection and Prevention systems (IDS/IPS), hardware configured with NIST security checklists, encrypted communications, hardware configured with a deny all/except approach, auditing, and correlation of audit logs from all systems. Management controls include but are not limited to: Certification and Accreditation (C&A), annual security assessments, monthly management of outstanding corrective action plans, ongoing risk assessments, and automated continuous monitoring. FAS: Not Applicable, no PII/PHI. STAR: All infrastructure supporting PII storage and use is in the HCQIS network which requires verified, authenticated Redshift - The computation engine for QuickSight, the cluster requires encryption at rest and in transit, contains full log auditing, has restrictive VPC Security Groups, and management of the cluster is restricted specifically to administrators. CDRAP Integration - Within the Redshift cluster, schemas will be mounted using role chaining: the IAM role assumed by the Redshift cluster assumes the role maintained by the CDRAP team.
S3 Storage - All buckets have block public access rules enabled at the org and bucket level. Access Control Lists and policies are attached to constrain use to QuickSight and the AWS administrative account. QuickSight IAM - For users to be able to access their organizational data, STAR integrates with HARP SavyInt to map SavyInt roles to QuickSight groups. Security Officials approve or reject role requests to enforce least privilege. | ||
Identify the publicly-available URL: | CDRAP: https://ccsqdataanalytics.cms.gov/ FAS: https://fas.cms.gov/ STAR: Not Applicable for the general public. | ||
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? | Yes | ||
Is a disclaimer notice provided to users that follow external links to websites not owned or operated by HHS? | No | ||