12  Data Governance, IRB, Privacy, and Responsible Research

We work with sensitive human-related data: clinical records, claims and pharmacy data, biomarkers, surveillance data, and repository datasets governed by strict use agreements. Mishandling any of it can harm people and end projects. This chapter is mandatory reading for everyone, and the standalone policy in data-governance is the authoritative reference.

12.1 Core principle

Access is a privilege tied to training, approval, and need. We collect the minimum, protect it rigorously, and honor every agreement that lets us use it.

12.2 Human-subjects training and IRB

Before touching any human-subjects data (including tissues, raw data, or derived data), you must:

  1. Complete and maintain CITI Program training appropriate to your role — typically Biomedical Research (Basic), Responsible Conduct of Research, Data or Specimens, Conflicts of Interest, and Information Privacy for Researchers. Add bloodborne-pathogen training if any biospecimen work applies.
  2. Be added by name to the approved IRB protocol for your project. If you are not on the protocol, you cannot access the data or participate in the project — no exceptions.
  3. Confirm the IRB-of-record for your project (it varies by institution and partnership).
ImportantPlaceholder: IRB and training specifics

The IRB-of-record, protocol numbers, CITI institutional affiliation, and required module list must be confirmed per project with the PI. Links and exact requirements are recorded in each project’s pod charter. Do not assume; ask.

12.3 Dataset-specific rules

Each dataset we use carries its own Data Use Agreement (DUA) and access rules. These are not interchangeable. Common examples:

Resource Typical governance considerations
PR DoH / ASES claims & pharmacy DUA terms, de-identification, approved analysts only, secure environment
BioLINCC Application, DUA, data security plan, no re-identification, citation requirements
BioData Catalyst / All of Us Workbench Cloud workspace, registered/controlled tiers, no data egress, workbench-only analysis
MESA, Framingham, AsthmaNet, NHANES Repository-specific use terms, acknowledgment language, redistribution limits

The Data Steward for each pod owns compliance with that project’s DUA. Before you analyze, confirm with the steward: What tier is this? Where must analysis happen? What can leave the environment? What must be cited or acknowledged?

Use the Data-Use and Access Checklist at the start of every project.

12.4 De-identification and HIPAA-adjacent thinking

Even when data are de-identified, we treat them with care:

  • Never attempt re-identification of any individual, ever.
  • Apply de-identification standards (e.g., removing or transforming direct identifiers; respecting small-cell suppression so individuals can’t be inferred).
  • Report results at aggregate levels that protect individuals; watch out for small cells in stratified (equity) analyses.
  • Treat claims, pharmacy, and clinical data as HIPAA-adjacent: handle them with the caution you’d give protected health information even when a project is technically outside HIPAA’s direct scope.

12.5 Access control and secure storage

  • Least privilege: people get access only to what their role requires.
  • No restricted data in general channels. Never put restricted or identifiable data in chat, email, personal drives, personal laptops, or public repos.
  • Analyze where the agreement says to. For controlled-tier repositories, analysis stays inside the approved workbench/environment; no downloading or egress unless explicitly permitted.
  • Secrets stay out of code. No credentials, tokens, or keys in GitHub. Use environment variables and a .gitignore that excludes data and secrets.
  • Encryption and backups follow institutional policy for any local handling that is permitted.

12.6 Aliquary governance

Aliquary is our sample-inventory system of record (Section 17.5). Its data-governance profile must fit the same access and DUA discipline we apply everywhere else:

  • De-identified data only. Do not enter names, MRNs, direct identifiers, or anything that could re-identify a person. Sample records use study IDs and inventory metadata — never PHI.
  • Tenant isolation. Each lab’s inventory is isolated from others; do not share credentials or copy another tenant’s data.
  • Complete audit trail. Registration, moves, aliquots, and freeze–thaw events are logged; treat the trail as part of the scientific record.
  • Full export, no lock-in. Inventories can be exported when a project archives, migrates, or ends. We do not trap sample records in a closed system.

Access to Aliquary follows least privilege and need-to-know, the same as any other controlled tool: provisioned when a member’s role requires sample work, recorded on the Data-Use and Access Checklist when inventory access is part of a project, and revoked at offboarding (Chapter 20). Aliquary does not replace IRB listing, CITI training, or dataset DUAs — it is inventory infrastructure sitting under those authorizations.

NoteTransparency: Aliquary and FERMLLC

Aliquary is a product of Felix E. Rivera-Mariani, PhD, LLC (FERMLLC) — the same parent LLC under which the RIPLRT Institute operates. It is a sibling in-house product, not a third-party vendor and not the RIPLRT Institute itself. We state that relationship here so members, partners, and reviewers can see the affiliation plainly.

12.7 Privacy of people — including us

  • No photos or videos of human research participants, ever — that violates privacy and IRB rules.
  • Photos/videos of group members require consent before capture, and any public posting requires PI approval.
  • Respect the privacy of community partners and participants in everything we publish or post.

12.8 Responsible research conduct

  • No fabrication, falsification, or plagiarism. A negative result is still a result.
  • Document analyses so they are reproducible (Chapter 13); reproducibility is a privacy-and-integrity control, not just a quality one.
  • Disclose conflicts of interest per institutional policy.
  • Follow sponsor terms and data-sharing/publication requirements of each dataset and grant.

12.8.1 Which institution governs your data

Before you request or touch any dataset, know which umbrella you are working under (Section 2.2) — it sets which IRB, training, and data-use agreement apply.

Your umbrella IRB of record Training & agreements
EBDL / Lynn University Lynn University IRB Lynn CITI, Lynn IRB listing, Lynn-approved DUAs
UPR-affiliated UPR IRB (or reliance, as applicable) UPR CITI/IRB listing; collaboration/DUA terms
RIPLRT / LLC (non-Lynn, non-UPR) Protocol named in the project charter Sponsor terms + LLC data-use rules

When a project spans institutions (e.g., a Lynn member analyzing UPR-sourceddata), the most restrictive applicable terms govern, and the data-use agreement controls. When in doubt, ask the PI before access is provisioned.

12.9 When something goes wrong

If you suspect a data breach, an access error, a consent problem, or a possible integrity issue:

  1. Stop the activity in question.
  2. Tell the PI and the Data Steward immediately — early reporting protects you and the people in the data.
  3. Document what happened factually.

This is explicitly a no-blame, report-early expectation. The only serious mistake is hiding the problem.