> For the complete documentation index, see [llms.txt](https://wiki.medicaiddatalearningnetwork.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.medicaiddatalearningnetwork.org/getting-started/working-in-the-vrdc.md). # Working in the VRDC {% hint style="info" icon="pen-to-square" %} Contributed by Patrick Thompson () {% endhint %} {% hint style="info" %} Editor's Note: When requesting TAF data through ResDAC, users can generally choose to access the files through the CMS Virtual Research Data Center (VRDC) or receive physical data files, depending on their project needs, institutional infrastructure, and CMS approval requirements. Additional helpful guidance on using the VRDC may be found at . {% endhint %} ## Overview The Virtual Research Data Center (VRDC) is a remote-access analytic environment within the Chronic Conditions Data Warehouse (CCW) where researchers access and analyze Centers for Medicare & Medicaid Services (CMS) program data, including the Transformed Medicaid Statistical Information System (T-MSIS) Analytic Files (TAF). Access requires an approved Research Identifiable File (RIF) Data Use Agreement (DUA), an individual researcher "seat" with an associated fee, and multi-factor authentication (MFA). The primary analytic tool is SAS Enterprise Guide. Additional tools including Databricks, R, and Python are available in the full CCW VRDC option (which includes additional tools compared to the SAS-only tier). CMS, the CCW, and the Research Data Assistance Center (ResDAC) maintain substantial formal documentation covering the access request process, DUAs, and file structures. However, there is comparatively little practitioner-level guidance addressing the experiential knowledge that new users need during their first months in the environment. This article aims to fill that gap. ## About This Article This article is written from the perspective of a new VRDC user with approximately 4.5 months of active use as of the time of writing, beginning December 2025. The author's newcomer status is both a limitation and a feature: the learning curve is recent, and the pitfalls encountered are likely representative of what new users face today. The focus is narrow and intentional: common pitfalls, undocumented friction points, and known gaps where formal documentation is absent or insufficient. This article supplements the formal documentation listed in the References section. It does not attempt to reproduce or summarize that documentation. The following topics are explicitly outside scope: the DUA application process, IRB/HIPAA waiver requirements, ResDAC submission procedures, Medicare-specific workflows, Databricks/R/Python/Stata workflows, and state-specific data quality variation beyond general Data Quality (DQ) Atlas guidance. ## Pitfalls and Undocumented Friction The following are drawn from the author's direct experience and were not found in the formal documentation sources reviewed. ### Getting Connected **Username must be lowercase**. A case mismatch produces a cryptic error rather than a clear message. This is not noted in the onboarding materials reviewed. **Install Okta Verify** before your first login attempt. VRDC access requires multi-factor authentication through Okta. Three factors are available: Okta Verify (mobile push notifications), SMS, and voice call. The CCW Okta Factor Enrollment and Management Guide recommends enrolling in at least two factors. Okta Verify is the most convenient for daily use. Users who do not have the app installed before their first CCW login will be unable to complete authentication. ### Working in the SAS Environment **Understand the local vs. server distinction**. Library configuration, autoexec behavior, and file paths differ between local SAS and the server connection. This distinction is not addressed in the sources reviewed but significantly affects how you organize your work. **Copy-paste is one-directional**. You can paste text into the VRDC environment, but you cannot copy text out. This is a security control, not a bug. It is not mentioned in the onboarding materials reviewed and catches new users off guard. **Use views rather than materializing tables where possible**. TAF-scale data can quickly consume your disk allocation. The CCW monitors space and notifies researchers, but proactive monitoring is preferable. **Periodically check and clear the WORK library**. Monitor its size against your allocation between sessions. ### Moving Data In and Out **"Downloading" and "uploading" terminology is inverted**. What feels like downloading output to your local machine is actually the output review submission process through the File Transfer Request System (FTRS). Researchers upload files into the FTRS Output folder. The CCW analytical team then reviews all output for disclosure checks before transferring it for download. Each DUA is allowed three output reviews per week (rolling seven days), shared by all researchers on the DUA, with a maximum of 1 GB per week. **Uploading external files (e.g., reference code tables, crosswalks) into your workspace is a distinct, separate action.** New users regularly conflate these two processes. **Download confirmation cue.** You know your file downloaded correctly when it appears on the download page. This confirmation step is not described in the sources reviewed. ### Output Review and Disclosure **Cell suppression applies to values of 1 through 10**. The CMS cell size suppression policy states that no cell containing a value of 1 to 10 may be reported directly, and no cell may be reported that allows a value of 1 to 10 to be derived from other reported cells or information, including through percentages or other mathematical formulas. A value of zero does not require suppression because it reveals no individual-level information. **Counter-suppression is required but not well documented.** When a small cell is suppressed, at least one additional cell must also be suppressed to prevent back-calculation. The formal policy states this rule clearly, but the author did not find step-by-step implementation guidance for researchers building multi-cell tables. In practice: do not include row or column totals that would allow a suppressed cell to be derived. ## References * CCW "About the VRDC": * CCW FAQ: * Output Review Process: * CMS Cell Size Suppression Policy: * ResDAC VRDC Overview and VRDC FAQs: * CCW Output Review Do's and Don'ts: * CCW Okta Factor Enrollment and Management Guide: --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://wiki.medicaiddatalearningnetwork.org/getting-started/working-in-the-vrdc.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.