Request Form

Submit a request through the CCSQ Data & Analytics Request Form to start the contribution process. The request will be reviewed and prioritized by the CMS Business Owners of the CDR. Use the following as a guide for what information to include in the request.

Required Information

The following information is required to be included in the request to become a contributor:

• A short description of the data with the minimum required information.
• The data dictionary with the minimum required information.
• The point of contact for the contribution effort.
• The anticipated timeline to load, validate, and release data to end users.
• The list of any validation groups that will require access to the pre-prod data for testing.
• The Enterprise Privacy Policy Engine (EPPE) DUA Entry associated with this data.
• The Access Control Model

The CDR will need one of the following for support purposes to forward user inquiries specific to the data:

• A CCSQ ServiceNow Support Group name
• A support email address

The team will also need to know:

• The access control model for this data (see below).
• Whether a data catalog entry can be made for this data on the public data catalog or if access to the data documentation should be restricted.

Required Data Documentation

All documentation submitted for contributed data must meet the minimum required standards as outlined below.

Short Description

Short description of data must include the following:

• Title - The name of the dataset or resource.
• Domain - The category of the resource such as (eg., Clinical, Provider, Claims, Beneficiary)
• Source - The system or activity that generates or provides the dataset.
• Granularity - The level of data detail that the resource covers, such as Atomic, Aggregated, Hybrid
• Load/Refresh Frequency - How often this data source will be refreshed/updated.
• Geographic Scope - What level of geographic scope this data entails (e.g., national, regional, state, county, zip)
• Timespan Covered - What timespan this data covers (e.g., 2019-2022)
• Personally Identifiable Information (PII)/Protected Health Information (PHI)/Sensitive Information - Whether this data contains PII/PHI/Other Sensitive information or not.

Data Dictionary

At minimum, documentation for the data contributed to the CDR should be in the form of a data dictionary that includes:

• Table name
• Table description
• Field Name (Short Name)
• Field Name (Long Name)
• Data Type/Length
• Field Description (provide details)
• Possible Values/Range
• Partition Key
• Comments

Data Documentation Format

Submitted data documentation should be in a comma-separated values (CSV) format that meets the required data dictionary template.

Required Data Format

The preferred data format for partnering systems is parquet due to superior performance and lower storage cost. However, CSV or JavaScript Object Notation (JSON) may also be used. This data should be stored in the partnering Application Development Organization’s (ADO's) Simple Storage Service (S3) bucket. It is also recommended to create directory versioning so that if parquet files need to be re-created, they can be created in a different version directory and not impact the current parquet files.

• Preferred Data Format: Parquet
• Accepted Data Formats: CSV, JSON

Access Control Model

The access control model refers to how contributors would like to restrict or grant access to the data that they are contributing. The CDR supports two access control models:

• Automated (DUA Based)
  • Access to this data will automatically be granted to any end user organization that has the appropriate DUA entry on their DUA. Contributors will provide the DUA entry that corresponds to the contributed data.
• Manual (Notification Based)
  • In addition to the DUA entry, access to this data is manually approved by the Business Owners of the data. End user organizations request access to the data, and we notify the Business Owners for either approval or rejection.

Contributors must  indicate which access model they would like to utilize for your data.

CDR Onboarding Steps

Onboarding into the CDR is central to becoming a Data Contributor. If the prospective contributor is not already onboarded, see the training and onboarding page for more information.

Being onboarded into the CDR comes with the following automatically provisioned resources for the contributor's organization/group:

• A production database/schema
• A pre-production (test) database/schema
• A Service Principal/Service Account

Once onboarded, the team will generate a schema specific to the contributor's BYOD data in accordance with CMS Data Taxonomy.

Contribution Workflow

The following is a generalized workflow that outlines the steps involved in contributing to the CDR. 

Cross Account Access

A contributor's data (parquet files) are stored in their own Simple Storage Service (S3) bucket so cross-account access must be established to allow CDR necessary access to the S3 bucket. CDR has adapted the resource-based policies and Amazon Web Services (AWS) identity and access management (IAM) policies method for accessing cross-account S3 bucket documented on AWS Support. In this case, the partnering contributor is "Account A", and CDR is "Account B".  Data encryption is highly recommended either with the standard AWS server-side encryption or custom key stores. 

Below is an example of a resource-based policy with custom key stores configuration from a partnering contributor.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
	        "Sid": "GrantS3BucketAccessToCDR", 
            "Action": [
                "s3:GetObject*",
				"s3:List*",
  				"s3:SelectObjectContent",
    			"kms:Encrypt",
    			"kms:Decrypt",
    			"kms:ReEncrypt*",
    			"kms:GenerateDataKey*",
    			"kms:DescribeKey"],
            "Resource": [
				"arn:aws:s3:::AccountABucketName/*",
				"arn:aws:s3:::AccountABucketName/",
				"arn:aws:s3:::AccoutA:key/AccountAKMSKey"]
        }
    ]
}

Connecting to the CDR

Data Contributors may desire to contribute data to the CDR using either our suite of tools that they gain access to through onboarding or through their own external.

See the following articles for details on making inbound and outbound connections to or from the CDR.

• For accessing an external database through the CDR, see this article on making Outbound Database Connections through the CDR.
• For accessing an external datastore through the CDR, see this article on making Outbound Datastore Connections through the CDR.
• For using an external tool to connect to the CDR Datastore to write data to the CDR, see this article on making Inbound Connections to the CDR Datastore.

Validating Contributed Data

A contributor's service principle is for automated, system to system connections only. Validation should be done through user accounts associated with the designated validation group - a contributor's group will be automatically provisioned validation access.

Ensure that any users performing validation request the HCQIS Access Roles and Profile (HARP) role for the appropriate group so that they can access the data in the CDR.

Changes to Data or Data Documentation

Data Contributors are expected to notify the CDR team of any changes to their data or the data documentation. Submit a request through the CCSQ Data & Analytics Request Form in advance of any changes, outlining the expected changes and with any new documentation attached. 

Reporting Issues

Data Contributors are responsible for informing the Data & Analytics team when there is an issue with