Chapter Leads: Shawn O’Neil, Mariam Deacy
N3C is strongly committed to patient privacy. After all, N3C is the steward for EHR data on millions of patients from dozens of healthcare organizations who’ve placed their trust in N3C’s ability to protect it. Some of these protections include agreeing to report a data leak incident within 2 business days (covered by the Data Use Agreements, discussed in Chapter 5), a formal review process to export any results derived from the data, and a formal per-project, per-person application process for data access.
This last protection, known as a Data Use Request or DUR, will be the main focus of this chapter. The DUR form is available only inside the N3C Data Enclave, so Enclave access is required to request data access. N3C registration and Enclave access are covered in Chapter 5, so we won’t cover those topics here.
6.1 Background: N3C Protected Data Levels
Not all data in the N3C Data Enclave requires an approved DUR to access-mock datasets and publicly-available data (e.g., US census data) are accessible by everyone with Enclave access. These low-risk data are covered more in Chapters 7 and 10.
The harmonized EHR data that do require an approved DUR to access are made available in two different “levels” (known as Level 2 and Level 3 for historical reasons–see below), each with different amounts of data obfuscation, and correspondingly different access requirements. Deciding which level of data is appropriate for your study is important, because accessing Level 3 data is more work and restrictive than accessing Level 2 data. On the other hand, some studies can be accomplished with only Level 3 data. Note that if you start with a lower level of data, it is possible to “upgrade” a project’s access level, though all participants in the project will need to complete another DUR for the new level.
In addition to the primary Level 2 and 3 datasets are “PPRL” data. PPRL data includes extra non-EHR sources of information such as obituary-based mortality records and viral variant sequencing information. These are available alongside only Level 3 data as an optional add-on; we’ll discuss PPRL in more detail below.
In order to preserve the ethical use of unconsented data for public health benefit, every attempt to obscure identities of institutions, communities, or individuals contributing data should be taken as shown here. Access to EHR-derived data should minimize privacy and never provide more access to identifiers than is required for the research question.
6.1.1 Level 3, Limited Data Set (LDS)
Level 3, or LDS data is the most complete and protected (the term “limited data set” is defined by HIPAA and may contain a limited set of potentially identifying information). This dataset contains two pieces of Protected Health Information (PHI) defined by HIPAA: full, 5-digit patient zip codes,1 and accurate dates of events and services (except for dates of birth which are limited to month and year).2 Level 3 data are in the OMOP common data model, with some N3C-specific additions and conveniences, and are versioned as releases as described above. (OMOP and N3C-specific additions are covered in Chapter 7.)
6.1.2 Level 2, De-Identified
Level 2 data, also known as De-Identified data, contains nearly the same information as the Level 3 data, but the two PHI-containing fields are further anonymized. Zip codes available in Level 3 are truncated to just the first 3 digits, and all recorded dates are shifted randomly, where the range of the random shift is ±180 days.3 This is not as dramatic a research limitation as it may seem, because the random shift amount is determined per patient: all dates for a given patient are shifted by the same (unknown, random) amount, allowing identifying sets of patients who had, for example, a positive COVID-19 PCR test and within 14 days received a given drug treatment.4 Level 2 data would not be appropriate for studies considering absolute timing, such as whether a patients’ primary COVID infection occurred during the Delta wave. Such questions are best answered by the LDS data.
The Level 2 data are also in OMOP format and versioned as releases. We’ll forgo examples of notional data because the format is exactly the same as for Level 3, LDS data.
6.1.3 Level 1, (Synthetic, Deprecated)
Level 1 data are no longer available. Previously, these data contained “synthetic” data generated via statistical processes to match specific aspects of the Level 3 data. We include this section here for historical context.
6.1.4 Example N3C OMOP Data Format
To give a sneak preview of the primary N3C data format, here’s a snapshot of a few columns of notional (fake) data in OMOP format from the condition_occurrence table:
data_partner_id, these are anonymized identifiers for sites contributing data, labeling each record with a source.
Notice in particular the columns for data_partner_id (a pseudo-random identifier assigned to each data partner), condition_concept_id (the OMOP identifier uniquely describing the condition used for data filtering and analysis), and condition_concept_name (the human-readable version of condition_concept_id, used for convenience but not for data filtering). Other OMOP tables link records by shared columns; here are a few columns from the person table describing basic demographics of patients:
person table.
Some other tables available with Level 3 data are specific to N3C; here are a few columns from a notional manifest table providing information about data partners, including the source CDM used by the data partner, the dates of data extraction and submission to N3C, and whether the data partner performs random date shifting prior to submission to N3C:
manifest table. This table provides information about data partners, such as their source common data model (cdm_name), whether they pre-shift dates (see Chapter 3), and when their last submission was.
6.1.5 PPRL Data
PPRL, short for “Privacy-Preserving Record Linkage”, is a strong cryptographic data handling technique allowing for the matching of records about individuals from different data sources, without revealing to any party except the data sources themselves any identifying information about the individual. While we won’t describe how the process works here, researchers with Enclave access can read more about it in Chapter 7 and the Introduction section of the PPRL training module in the Training Portal (see Section 11.4).
6.2 Level 2/3 (and PPRL) Availability
Level 3, LDS data are available only to researchers affiliated with US-based organizations such as universities and medical schools. As we’ll discuss below, the most significant access requirement for Level 3 data is a letter of determination from the researchers’ local Institutional Review Board (IRB), so this level of data is also available to other US-based organizations with the ability to work with an Institutional Review Board, or IRB (e.g., pharmaceutical companies).
Level 2, De-Identified data are available to researchers at both US and approved foreign organizations (those that can sign an institutional Data Use Agreement (DUA), see Chapter 3).
PPRL data can be accessed alongside only Level 3 (LDS) data, and as such has the same access availability. As we’ll discuss below, there are special procedures for gaining access to PPRL data as part of a Level 3 access request.
6.3 Workspaces, Permissions, and the Data Catalog
The N3C Data Enclave uses a fine-grained permissions model to manage researcher access to protected data. While researchers are not able to modify these permissions themselves, understanding them will help in navigating the DUR process and subsequent work.
Data management in the Enclave is centered around “project workspaces” which act like folders-workspaces are indicated by a small filing-drawer icon and are listed under the “Projects & files” link in the left navigation menu.
Workspaces are used for multiple purposes. Some store the Level 1/2/3 data; the “LDS Release” workspace for example stores the tables for the Level 3 LDS data. (The Data Catalog provides a more efficient way to access these tables however, more on that below.) Some are used to store “external” datasets such as publicly-available US Census data (see Section 7.6). The “N3C Training Area” workspace can be accessed by anyone as a place to practice on notional data (see Section 11.6). Most, however, house research projects, and these are indicated with an RP-XXXXXX prefix.
Work in one project workspace can access only data or files from another project workspace if a “reference” has been added from the former to the latter. Researchers do not have permission to add such references. Thus, access from a research project workspace to protected datasets is possible only if the appropriate references have been added by administrators, which is done after a corresponding Data Use Request has been approved. Said another way, rather than providing researchers access to data, researchers are provided access to project workspaces, and these are in turn provided access to data.
This reference-based permission scheme supports a number of useful features for N3C. Naturally, restricting workspace access to a subset of data affords the possibility of different levels of data access with correspondingly different access requirements. A single researcher may be involved with multiple research projects of different levels but cannot share data or files across them, thus it is impossible for a researcher with access to Level 3 data to share it with their colleagues in another project with Level 2 data.
Shared workspaces facilitating secure, collaborative data access are not unique to N3C amongst cloud-hosted, centralized RWD environments. These technologies, coupled with appropriate governance and team-science principles, can facilitate successful research projects in the face of data complexity.
6.4 The DUR - Data Use Request
6.4.1 Project Roles and DUR Types
In the simplest view, each research project is associated with a single ‘DUR’ listing the project title and abstract, and governing the level of data accessible to the project workspace (and thus also to all researchers with access to that workspace). DURs are reviewed by the N3C Data Access Committee (DAC), and when approved administrators configure the workspace and researcher access to it.
In practice the situation is a bit more complicated. The researcher who submits the initial DUR defining the title, abstract, and data access level is known as the project lead. Other researchers who sign on to the project submit “collaborator DURs”. A collaborator DUR is a copy of the original DUR submitted by the lead, but the title, abstract, and data access level are fixed. Both leads and collaborators must enter other requirements depending on the data access level (e.g., date of most recent Human Subjects Research Protection training or local IRB approval), and both lead and collaborator DURs are reviewed by the DAC before access is granted. If a lead’s DUR is rejected by the DAC, they will have the opportunity to appeal by updating the information provided.
The lead has certain abilities and responsibilities, most importantly configuring whether the project is open so that other researchers may request to join as collaborators, and if so periodically reviewing those requests. These cannot be delegated, so the lead should be someone with that decision-making authority. Aside from these aspects however, leads and collaborators all have the same permissions in the project workspace and can review and share work.
Since DURs expire after one year, there is also a “renewal” DUR type, which both leads and collaborators are prompted to fill in the weeks prior to their DUR expiry via email. Renewal DURs don’t allow editing the title, abstract, or data level, and so are usually expedited by the DAC.
Lastly, there are “revision” DURs, where the lead requests to change some major feature of the DUR (most commonly to upgrade the data access level) for an existing project workspace. Once approved by the DAC, administrators reach out to the lead to plan the revision, because collaborators will also need to submit new collaborator DURs prior to the change or they will lose access to the workspace.
Note that while we’ve described these different types of DURs, they all use the same DUR form, with the differences boiling down to what fields can be changed by the researcher filling it out.
Theoretically a single researcher may have multiple outstanding DURs for the same project. For example, the lead for a project nearing its expiry may submit a renewal DUR, and while that renewal is pending DAC approval the lead may also decide to submit a revision DUR to access a higher level of data. Most likely the renewal will be approved first, followed by the revision. If it so happens that the revision is approved before the renewal, the renewal request will then be moot as revision also resets the expiry date. Such cases may require intervention by administrative support, so it is wise to be judicious about DUR submissions to expedite the process.
6.5 DUR Dashboards
There are three primary dashboards used to create and manage DURs; all three are linked from the N3C Data Enclave homepage via buttons titled “Data Use Request (DUR)”, “My Projects (DURs)”, and “Explore Projects (DURs)”
Although there is some functionality overlap, the primary uses for these three dashboards are:
Data Use Request (DUR) is used to submit a new Data Use Request for a new project. The submitter provides the project abstract and title and selects the data level needed, and will become the lead for the project.
My Projects (DURs) shows the status of your submitted requests and projects. This interface also provides some project management functionality for leads, such as linking a project to an N3C domain team, reviewing requests from potential collaborators to join the project, appealing rejected DUR submissions, and accessing the download request dashboard.
Explore Projects (DURs) lists all N3C research projects, and for those that allow it, provides a link to request to join a project by submitting a collaborator DUR.
6.6 Data Use Request (DUR): Initiate a New Research Project
This first dashboard is really just the DUR form itself, and is used to request the creation of, and access to, a brand-new research project with access to one of the levels of protected N3C data. The form has a number of sections, and some of these are dynamic, depending on choices to earlier questions. The left side of the DUR form provides quick links to other dashboards or actions; “Create a New Project” simply refreshes the page (since we are already creating a new project DUR), “Request to become a collaborator on an existing project” opens the Explore Projects dashboard (discussed below), and Public Health Proposal opens the application form for the N3C PHASTR initiative (which utilizes a specialized variant of the DUR process discussed here).
Moving to the main content of the DUR form, the first three questions prompt for a Title, Abstract, and Research Project Rationale. (The green Submit button is always visible, and will be clickable when all fields for the DUR are properly completed.) Title and Abstract are self-descriptive, but know that these entries will be listed for others to see, both inside the N3C Data Enclave via the Explore Projects dashboard, and outside at https://covid.cd2h.org/dashboard/.
The Research Project Rationale deserves special attention. This information will be visible only to you (the submitter) and the Data Access Committee (DAC) who will approve or deny the request. The project rationale should describe for the DAC why data access is being requested in light of the goals of the research project. The rationale should include a justification for the level of data being requested, especially if requesting the Level 3 Limited Data Set (LDS). If your project doesn’t require the accurate dates or full patient zip codes provided by Level 3 data, it will be rejected, or approved for the Level 2 data even though Level 3 was requested. Similarly, if requesting access to any PPRL (see Section 6.2) datasets the rationale should include why. (You will also need to have the PPRL data mentioned in your IRB letter of determination - see below.)
The next questions pertain to potential collaborations. The “Please associate your project with an existing N3C Domain Team” prompts you to select a domain team that best fits your project. Domain Teams are N3C working groups encompassing multiple research projects and are used to facilitate collaboration. Linking your project to a domain team this way in the Enclave allows others to navigate domain teams and browse linked projects dynamically. It is possible to modify this linkage later, so if you aren’t sure feel free to check the “need help choosing” check box.
The next question, “Allow other researchers to join this project”, configures the project so that others can request to join via the Explore Projects dashboard. If this is enabled, other researchers will be able to fill out a collaborator DUR (a copy of this DUR but with the title, abstract, and data level fixed). As the lead submitting this primary DUR, you will have the opportunity to approve or deny such requests (via the My Projects dashboard); if you approve, their request will be forwarded to the DAC for final approval of the workspace and data. This option can be changed later.
The Collaborators section allows you to send invites to potential collaborators to join the project. Added collaborators will receive an email notification (with instructions to register for N3C in case they don’t already have access), and will see the invite in their My Projects dashboard with a link to fill out a collaboration DUR (much like those who request to join described above). These invites are sent regardless of the earlier choice to Allow/Do not allow others to join the project.
Next is the choice of data level to request. Levels 2 and 3 require additional information, so we’ll start with the Level 1 data and return to see the differences for Levels 2 and 3.
6.6.1 Base DUR Requirements
For both level 2 and Level 3 access, the first requirements are that you have read and attested to the Data Use Agreement, and that you have completed the required NIH IT Security training course within the past year. Both of these are also required as part of onboarding, so we won’t cover them here (see Chapter 5).
Next, you will need to attest to having read the N3C Code of Conduct (with the text provided above), that you have read and understood the N3C download policy (a link is provided via the more information icon), and that if you choose to use any additional data sources in connection with N3C protected data that you are aware of your institutions’ policies around doing so. (Some institutions restrict how and when EHR data can be linked to other datasets, including publicly available data ingested for use by N3C researchers.)
With all of this information provided, you will be able to click Submit and send the request to the Data Access Committee for review.
6.6.2 Level 2 DUR Requirements
Requesting access to Level 2, De-Identified data requires additional information. First, when selecting the Level 2 request option, you will be asked to confirm that you have taken Human Subjects Research Protection training within the last three years and provide the date of completion. Most research institutions provide specific training courses to satisfy this requirement, for example via the CITI Program. The specific courses required vary from institution to institution, so check with your research office or equivalent authority for guidance. If your institution does not offer or recommend specific courses, you can utilize the free course provided by Health and Human Services.
In addition to human subjects research protection training, you will need to consider whether your institution requires a letter of determination from your local IRB when using De-Identified data. If so, you’ll be prompted to upload the letter as a PDF before you can submit the DUR.
6.6.3 Level 3 DUR Requirements
The Level 3, Limited Data Set (LDS) offers the most complete view of N3C data. Unlike Level 2 De-Identified data, dates are not shifted (for most contributing data partners) and 5-digit patient zip codes are available (for most zip codes). See Chapter 3 for more details
Level 3 DURs require the same attestations and human subjects research protection training as Level 2 DURs. A Level 3 DUR also allows researchers to request access to one or more supplemental PPRL datasets providing additional information about patients. These provide additional mortality information, viral variant records, and claims data from the Centers for Medicare and Medicaid Services, but are available only for subsets of N3C patients (see Chapter 7 for details about PPRL).
A Level 3 DUR additionally requires a letter of determination from the submitter’s local IRB:
Note that when requesting access to PPRL datasets, both the Research Project Rationale (reviewed by the DAC) and the IRB letter of determination should address the need for the PPRL datasets requested. Failure to adequately justify the use of PPRL datasets may result in denial of the DUR, or approval with lack of PPRL dataset access.
6.6.4 Project Workspace Creation and Data Access
The Data Access Committee reviews all DURs. After a new project DUR is approved, a workspace is created inside the Enclave with access to the approved datasets (see Workspaces, Permissions, and the Data Catalog above), and the submitting lead is given access to this project workspace. An email is also sent to the submitting lead with links to useful learning resources.
The full review and access process varies depending on the level of data requested and workload of the DAC, but most DURs are evaluated within 2 weeks. The status of your DUR will be shown in the My Projects dashboard (below). If a submitted DUR has not received any update for longer than two weeks, you should submit a request for a follow-up to the Enclave-external ticket support system.
6.7 Explore Projects (DURs): Browse and Join Projects
Although all N3C research projects are listed in the public dashboard, the Explore Projects dashboard within the N3C Data Enclave allows researchers to request to join projects that allow for it as collaborators.
First, let’s explore the dashboard. The initial list of projects shown is “Projects to join” – these have been configured by the project lead to allow any N3C researcher to request access to the project for collaboration. Below this list are two expandable sections, “Projects to Explore” listing projects that do not allow requests to join, and “Operational Projects (N3C Technical Development)” listing DURs used by the data ingestion and harmonization teams and others.
The “Search Projects” field is helpful in finding one of the many N3C projects and supports searching in any of the shown text columns. The “Projects by N3C Domain Team” button shows the project list organized by domain team, which can be useful in identifying potential overlapping research. Finally, “Closed Projects” lists non-active projects, for example those whose 1-year expiry has passed without renewal.
To request to join a project, simply click its Request to Join link from the list. This opens up a collaborator DUR: a copy of the DUR submitted by the project lead, but the Title, Abstract, selected data level, and domain-team linkage are not changeable. You will need to complete the other requirements for the data level however (see above), including submitting a letter of determination from your local IRB if needed. If the DUR indicates that PPRL data are requested, your IRB letter should also reference these datasets. IRB determination letters are required for all Level 3 DURs, or if the DUR is Level 2 and your institution requires IRB review. (Note that the DUR form will not ask for an IRB letter if you are registered with N3C as being from the same institution as the project lead; in this case it is assumed that the lead’s already-submitted letter covers you as well.)
Collaborator DURs must first be approved by the project lead (via their My Projects dashboard, see below). You may thus want to reach out to the lead prior to requesting access to their project so they can expect the request. Once approved by the lead the DUR is sent to the DAC for final approval. After DAC approval you will be given access to the project workspace (see Workspaces, Permissions, and the Data Catalog above). Collaborator DURs are generally faster to approve than new project DURs, but as with new project DURs if no progress is made in two weeks you should submit a request for follow-up to the Enclave-external ticket support system.
As with new project DURs, the status of your submitted collaborator DURs can be found in the My Projects dashboard.
6.8 My Projects (DURs): DUR Invitations, Status, and Management for Leads
The My Projects dashboard, linked from the N3C Data Enclave homepage, shows the status of your Data Use Requests and allows leads to configure some parameters of their projects.
Along the left are the various projects you’ve requested access to, either as a lead who’s submitted a new project DUR, or as a collaborator who’s requested to join a project. Notice along the bottom the “Invitations to Submit a Project Collaborator DUR” – this section may be expanded, and if any leads have added you to their DUR as invited collaborators, you will see a link to fill out a collaborator DUR here. (This is the same process as requesting to join a project as described above.) A quick link to the Download Requests Dashboard is also provided near the top, which we won’t discuss further here. Nearby are two buttons for project leads, “Review Collaborator Requests for My Projects”, and “Manage My Projects”, both discussed below.
Having selected a project from the list, the interface shows a variety of information about the project, including the data access level, project lead, and a direct link to the project workspace. If you are a collaborator on the project rather than the lead, you will also see a button to voluntarily withdraw from the project, which will remove your access to the project workspace but leave intact your work within that workspace for your collaborators.
The table below shows the DURs you have submitted pertaining to the project. Usually this will list a single DUR, but as noted at the beginning of this chapter in theory you may have multiple outstanding DURs pertaining to the same project. The “DUR Review Status” column shows the state of the DUR, and may contain one of several values indicating its progress: “Pending Lead Investigator Approval” if the DUR still needs to be approved by the project lead (“Denied by Lead Investigator” if they deny the request), “Pending DAC Review” for DURs that have been approved by the lead and are awaiting DAC review (“Denied” for those DURs that have been denied by the DAC), “Reviewed and Pending Workspace Access” for DURs that are fully approved but awaiting permissions to be applied for project workspace access, and “Complete” for fully approved DURs with enabled data access.
If we scroll further to the right we see other important columns, particularly the Action and Renewal columns.
N3C DURs are valid for one year-continued access to the project workspace requires submitting a renewal DUR before the expiration date listed. The Renew DUR link in the Renewal column opens up a renewal DUR: a copy of the DUR with almost all information uneditable, but requiring re-attestation of information like the Data Use Agreement, Code of Conduct, and human subjects research protection training. Renewal DURs are processed more quickly than other types, but if you miss the renewal deadline and you are a collaborator (not the lead) you will need to resubmit a collaborator DUR for a more thorough review. Leads who miss the renewal deadline will have their projects closed and will need to submit an Enclave-external support ticket for help re-opening it.
If you are the lead for the project you will have the option to “Appeal” the DUR under the Action column to appeal a DUR rejected by the DAC. The appeal DUR is a copy of the submitted DUR, but all fields are editable, including Title, Abstract, data access level, and research project rationale. When appealing a rejected DUR, you will likely want to update at least the research project rationale. Finally, for active projects there will be an “Update DUR” option to request a significant change to an approved DUR requiring DAC review, such as updating a project to a higher level of data access.
6.8.1 Project Management for Leads
The My Projects dashboard provides some additional functionality for project leads not available to collaborators in addition to the Appeal link. First is the dashboard accessed via the “Review Collaborator Requests for My Projects” button. The projects for which you are a lead are listed along the left, and the requests to access that project are listed along the right. You can choose to approve or deny each request by selecting it and clicking the large blue “Approve Selected Collaborator Request” button. Collaborator access cannot be revoked this way, however.
Back in the My Projects dashboard, we can select the “Manage My Projects” button to see more project configuration options. The main configuration options are “Configure N3C Domain Teams” to modify the listed linkage between the project and domain teams, “Review Collaborator Requests for this Project” which opens the collaborator approval dashboard above, and “Allow or Disallow Collaborator Requests”. This last option enables or disables the “Request to Join” link for the project in the Explore Projects dashboard.
This chapter was first published May 2023. If you have suggested modifications or additions, please see How to Contribute on the book’s initial page.
There are some exceptions where five digit zip codes are not visible in Level 3 data: zip codes represented by fewer than 20,000 patients are removed altogether; sometimes only the first three digits of the zip code are displayed (such as zips with a predominantly American Indian/Alaskan Native population and zip codes from participating institutions who send only the first three digits).↩︎
In actuality, a few data partners also perform small amounts of date shifting-randomly shifting all dates on a per-patient basis to further protect patient privacy-prior to sending their data to N3C. The manifest information (described below) indicates which data partners do so and the range of potential shift so researchers can remove data from these partners if they need highly-accurate date information.↩︎
See Section 3.4.1.↩︎
Like Level 3 data, birth dates are available only at the year and month level, and these are similarly shifted along with other patient-associated dates. In Level 2 data birth date information is removed entirely for patients who are more than 90 years old, and a separate
is_age_90_or_oldercolumn identifies these individuals as a group.↩︎