HEART-GeN lab manual

Welcome to the HEART-GeN Lab

Welcome to the Health Equity for Advancing Research and Technology using Genomic Neuroscience (HEART-GeN) lab! As a member of the HEART-GeN lab, you are joining a group of diverse scientists. Our lab focuses on developing more equitable treatments for brain disorders that disproportionately affect Black communities. In this lab manual, you’ll learn more about the lab’s mission and values, as well as key information about getting started, working, and getting help in the lab. Remember, you are a valued member of the team, and you belong here just as much as anyone else!

What the HEART-GeN Lab is About

Our Scientific Mission and Vision

Our lab aims to improve therapeutics for underrepresented communities by investigating the influence of genetic ancestry on molecular signatures in the brain. We use computational tools and disease-relevant models, such as postmortem brain tissue, brain organoids, and iPSC-derived glial cells, to uncover how genetic ancestry affects complex traits in the brain. This integrative approach provides insights into the interplay between genetic and environmental factors in complex brain disorders.

We collaborate with communities to guide the development of impactful research. One of our lab’s main priorities is to train a diverse group of next-generation computational scientists who can communicate our findings to the community.

Our Values

As an interdisciplinary group, our lab values team science that prioritizes three core elements of scientific excellence:

1. Rigor, Reproducibility, and Transparency: We are committed to conducting honest research that adheres to the highest standards of scientific integrity. We acknowledge the challenges inherent in research, but we believe that transparency, open communication, and meticulous methodology are essential for generating reliable and impactful findings.
2. Diversity, Equity, and Inclusion: We believe that diverse perspectives and backgrounds are essential for achieving scientific breakthroughs. We foster a welcoming and inclusive environment where everyone feels valued and empowered to contribute their unique talents and expertise. This dedication to diversity strengthens our research and broadens our understanding of the world.
3. Mentoring and Collaboration: We believe in fostering a culture of mentorship and collaboration. We are dedicated to providing support, guidance, and learning opportunities to all members of our lab, regardless of their experience level. We value open dialogue, constructive criticism, and teamwork as essential elements for achieving scientific progress.

Communication in the HEART-GeN Lab

General Communication Policies

Open, honest, and respectful communication is essential within our lab. As such, I expect all members of the HEART-GeN lab to treat others with respect. This means treating others the way they want to be treated, sharing information openly, and listening carefully. Slack is our primary communication channel for day-to-day needs. Email is reserved for major administrative items and should be used infrequently.

Meetings in the Lab

Our lab has several types of recurring meetings.

Team Meetings

This weekly team meeting is an opportunity to discuss research underway in the lab. Every team member is expected to attend. We alternate between Journal Club and Research Updates. These meetings will be scheduled at the beginning of each quarter to maximize in-person attendance of all team members. Food will be provided, funding permitting. Meetings are expected to last one hour and will not exceed 75 minutes. All team meetings are hybrid by default.

During Research Updates meetings, every scientific team member should be prepared to give an update unless otherwise indicated. For timing, a three-slide outline is recommended: (1) previous work, (2) current work, (3) next steps. The first slide will give an overview of the progress the team member made during the previous week. The second slide will discuss what the team member plans to do during the current week. The last slide will discuss future plans and any problems they have encountered.

Administrative staff may give updates on any administrative tasks or goals that the lab should know about, including outreach efforts and any budgetary concerns.

One-on-One Individual Meetings

One-on-one meetings with Dr. Benjamin will be scheduled weekly for trainees and staff (research and administrative). For trainees, these meetings will be to discuss research progress and professional development. Trainees should expect to spend at least 15 minutes discussing professional development activities and goals.

Project-specific Meetings

Every project has a project-specific meeting to discuss project-related issues. These may include data preparation, data acquisition, data storage, and project design. These hour-long meetings will be divided into three parts: (1) project updates, (2) project concerns or problems, and (3) expected timeline for project deliverables. Project-specific meetings are expected at least once a quarter, with frequency tailored to the size of the team and project needs.

A project deliverable may include:

Deliverable	Item
Manuscript	Data acquisition
	Data preparation
	Data analysis
	Writing and/or editing
Software	Development
	Annotation
	Release
	Maintenance
Resource/Dataset	Development
	Maintenance
	Release

As-Needed Meetings

Beyond the regular scheduled meetings, we encourage open communication and collaboration through as-needed meetings. These meetings can be:

• One-on-one meetings: If you encounter a problem, have questions, or need guidance, feel free to request a meeting with me directly. This allows for focused discussions and personalized support.
• Team meetings: If an issue would benefit from the collective expertise of the lab, or a collaborative brainstorming session, an additional team meeting can be scheduled.
• Project-specific meetings: When launching a new project, we will schedule a dedicated meeting to discuss roles and procedures and ensure everyone is on the same page. This helps ensure a smooth and coordinated start.
• Data-focused meetings: Complex data analysis or manuscript discussions may require dedicated time beyond the regular team meeting. Feel free to propose a meeting with relevant team members to delve deeper.

I encourage all team members to take initiative and request these meetings as needed.

Communication Tools Used in the Lab

• Email: used for rare, large administrative communications
• Slack: informal communication for quick responses and the majority of day-to-day lab communication
• GitHub (via issues): research-related communication
• Video chat, phone calls, or text messages: meetings or communications that need to happen quickly

Slack Guidelines

To support effective communication and healthy work-life integration:

• Keep your Slack status updated, including when you are focused or away.
• Set working-hour notifications. Configure Slack so that messages outside your working hours do not disturb you, unless you choose to check them.

Booking Shared Meeting Space

The HEART-GeN Lab relies on shared conference rooms and meeting spaces across the Feinberg School of Medicine (FSM) for team meetings, project discussions, interviews, and collaborative work. Below are the standard procedures for identifying and reserving these spaces.

Where We Book Space

At Northwestern FSM, meeting spaces can be reserved through:

• Feinberg Room Scheduler (EMS WebApp) Most conference rooms – including those in Lurie, Simpson Querrey (SQBRC), Tarry, Searle, and McGaw – are booked through the campus-wide EMS platform. (Accessible with Northwestern credentials.)

• Departmentally Controlled Rooms Some rooms require approval from departmental administrators (e.g., rooms owned by the Department of Preventive Medicine, Neuroscience, or C2). If you receive an “approval required” response, forward the request to Dr. Benjamin or the appropriate administrative contact.

• SQBRC / Center-Specific Spaces Certain specialized rooms (e.g., classrooms, event spaces) are managed by SQBRC staff and require a separate request form or email approval.

General Booking Rules

When booking meeting space:

• Check availability through EMS or the appropriate department’s calendar.
• Book early – rooms fill quickly, especially Monday–Thursday between 9 AM and 3 PM.

• Always include:

  • Meeting title (e.g., “HEART-GeN Weekly Meeting”)
  • Expected number of attendees
  • AV needs (Zoom, hybrid setup, HDMI connection)
• Cancel reservations promptly if plans change so others can use the space.

Who Can Book

• All staff and trainees may request rooms for:

  • Project meetings
  • Journal club
  • Small-group collaboration
  • Interviews or visitor meetings

• Lab-wide meetings and high-profile collaborations should be coordinated by Dr. Benjamin or designated staff.

Hybrid Meeting Considerations

If hybrid attendance is expected:

• Prioritize rooms equipped with Zoom/Teams-enabled AV systems (common in Lurie and SQBRC).
• Test the equipment 5–10 minutes before the meeting.
• Bring a personal laptop as backup for screen sharing or audio.

If You Need Help Booking

If you cannot locate an appropriate room or something is unclear:

• Ask in the #general Slack channel.
• Contact Rachel Rodriguez about access-restricted rooms.

• Ask Dr. Benjamin for help if:

  • You need a larger room (>12 people)
  • You require recurring reservations
  • The booking system denies access

Best Practices

To keep things efficient and respectful:

• Book the smallest room that reasonably fits your group.
• Do not hold rooms longer than needed.
• Leave the space clean (whiteboards erased, trash removed, chairs reset).
• Log any AV issues via the building’s posted contact or facilities link.

Getting Started in the HEART-GeN Lab

Onboarding

As a new team member, you will go through an onboarding process to become acquainted with the team, projects, programming environment, and expectations. You can expect:

• Introductions and meetings with team members
• Training on programming, record-keeping, and institutional compliance
• Overview of current research projects and collaborative partnerships
• Review of lab policies, procedures, and documentation practices
• Discussion of your goals, interests, and professional development plan

General Guidance for New Team Members

Getting started in a new environment will take time. We don’t expect everyone to be up and running within a week! In general, new team members can expect it to take about a month to complete all onboarding tasks. Depending on your starting knowledge, you might spend several months learning basic computational skills and reading papers. There is no rush! At the HEART-GeN lab, we believe that building a strong foundation takes time and that everyone learns at a different pace.

New Team Member Essentials

HR information

• Department/University: Rachel Rodriguez will guide you through departmental and university onboarding.
• Lab-specific: You will receive several emails from either Dr. Benjamin or the lab manager inviting you to Slack and GitHub.

Lab culture

Headphones are required during normal work hours. Normal work hours are Monday to Friday from 0800 to 1800. Outside of those hours, please be respectful of your fellow team members.

New Team Member Onboarding Tasks

First-day tasks

• Join Slack
• Read the lab manual
• Obtain High-Performance Computing (HPC) cluster access (Quest and NSF ACCESS)
• Obtain access to lab-specific software
• Attend a goals meeting with Dr. Benjamin

First two weeks tasks

• Share information for lab website
  • Photo
  • Professional social media handles
  • GitHub account
• Trainees should also complete:
  • Individual development plan
  • Mentor-trainee compact
• Access to lab shared software
  • GitHub
  • Biorender
  • Zotero
  • LabArchives
• Computer setup

Note: If you do not have a GitHub account, we will work together to create one.

GitHub Setup

1. Create a personal GitHub account and verify your email address. Use a strong, unique password.
2. Enable two-factor authentication and store your recovery codes in a secure location.
3. Complete your profile with your name, a profile image, a brief biography, and relevant professional links. If you plan to pursue industry roles, treat your profile like a resume and ensure that pinned repositories and README files reflect your strongest work.
4. Add and verify your institutional email address. If you use a different address for commits, add and verify that address as well so that GitHub can connect your commits to your account.
5. Send your GitHub username to Dr. Benjamin or the lab manager and accept the invitation to the HEART-GeN organization and appropriate project teams.

6. Configure your name and a verified email address in Git on each computer or cluster where you will make commits:

   git config --global user.name "Your Name"
   git config --global user.email "your-email@example.edu"
   

7. Configure GitHub authentication using an SSH key by following the relevant instructions below. Never share a password, recovery code, personal access token, or private SSH key.

SSH Setup on a Local Computer

These commands work in Terminal on macOS or Linux and in Git Bash or the Windows Subsystem for Linux (WSL) on Windows.

1. Check for existing SSH keys:

   ls -al ~/.ssh
   

2. Create the SSH directory if needed, secure it, and generate a dedicated GitHub key. Use the email address associated with your GitHub account:

   mkdir -p ~/.ssh
   chmod 700 ~/.ssh
   ssh-keygen -t ed25519 -C "your-email@example.edu" -f ~/.ssh/id_ed25519_github
   

   Enter a secure passphrase when prompted. If the key file already exists, do not overwrite it without first confirming that it is safe to do so.

3. Start the SSH agent and add the private key:

   eval "$(ssh-agent -s)"
   ssh-add ~/.ssh/id_ed25519_github
   

4. Display the public key and copy the entire output. The public key ends in .pub; never display or share the private key without that extension.

   cat ~/.ssh/id_ed25519_github.pub
   

5. In GitHub, go to Settings → SSH and GPG keys → New SSH key. Give the key a descriptive title, such as Personal laptop, select Authentication Key, paste the public key, and save it.

6. Open or create ~/.ssh/config and add:

   Host github.com
     HostName github.com
     User git
     IdentityFile ~/.ssh/id_ed25519_github
     IdentitiesOnly yes
   

   Then secure the configuration file:

   chmod 600 ~/.ssh/config
   

7. Test the connection. On the first connection, verify and accept GitHub’s host key when prompted. A successful response will identify your GitHub username and note that GitHub does not provide shell access.

   ssh -T git@github.com
   

SSH Setup on Bridges-2

Generate a separate SSH key on Bridges-2. Do not copy a private key from your local computer to Bridges-2 or from Bridges-2 to your local computer.

1. Log in to Bridges-2 with your PSC username:

   ssh PSC-username@bridges2.psc.edu
   

2. On Bridges-2, check for existing keys, prepare the SSH directory, and generate a dedicated GitHub key:

   ls -al ~/.ssh
   mkdir -p ~/.ssh
   chmod 700 ~/.ssh
   ssh-keygen -t ed25519 -C "your-email@example.edu" -f ~/.ssh/id_ed25519_github_bridges2
   

3. Start the SSH agent and add the Bridges-2 private key:

   eval "$(ssh-agent -s)"
   ssh-add ~/.ssh/id_ed25519_github_bridges2
   

4. Display and copy the Bridges-2 public key:

   cat ~/.ssh/id_ed25519_github_bridges2.pub
   

5. Add this public key to GitHub → Settings → SSH and GPG keys as a new authentication key with a descriptive title, such as ACCESS Bridges-2. Do not replace your local computer’s key.

6. Open or create ~/.ssh/config on Bridges-2 and add:

   Host github.com
     HostName github.com
     User git
     IdentityFile ~/.ssh/id_ed25519_github_bridges2
     IdentitiesOnly yes
   

   Then secure the configuration file and test the connection:

   chmod 600 ~/.ssh/config
   ssh -T git@github.com
   

7. Use the repository’s SSH URL when cloning on Bridges-2:

   git clone git@github.com:heart-gen/REPOSITORY.git
   

   Replace REPOSITORY with the repository name. If a new shell session does not recognize the key, start ssh-agent and run ssh-add again.

See GitHub’s official account setup guide and SSH connection guide for more information.

ORCID Sign-Up

An ORCID iD is a persistent identifier that connects you with your research contributions throughout your career. If you do not already have one:

1. Register for an ORCID iD. Before creating a record, check whether ORCID finds an existing record for you; do not create a duplicate.
2. Verify your email address using the message sent by ORCID.
3. Add and verify both your institutional email address and a long-term personal email address so that you retain access when you change institutions. Email addresses are private by default.
4. Review the visibility setting for each item in your record. Your ORCID iD is always public, but you control the visibility of other information.
5. Add your current affiliation, education, works, funding, and professional website as applicable. Keep the record current and use your ORCID iD when submitting manuscripts, grant applications, or conference abstracts.
6. Share your ORCID iD with the lab for your website profile and other lab records.

See the official ORCID registration guide for additional help.

Lab Activities

• Professional Headshots: Each February, the lab organizes optional professional headshot sessions for anyone wanting updated photos for GitHub, LinkedIn, personal websites, and conference materials.
• Annual Writing Retreat: Every July, we hold a lab-wide writing retreat, focused on deep work, manuscript progress, and professional writing development.

Materials to Review

During your first couple of months in the lab, review materials will be tailored by project and experience. For example, if a new team member has limited programming experience, they will focus on learning basic programming. In addition to this, new members can expect to receive a collection of papers, protocols, and technical manuals that are specific to their project. During our one-on-one meetings, we will build a realistic time frame for developing the programming, statistics, and linear algebra skills necessary for all lab projects. It is always okay to ask for more background materials, even if they do not directly relate to your assigned project.

RNA-sequencing (bulk)

• RNA-Seq: a revolutionary tool for transcriptomics
• Advancing RNA-Seq analysis
• Systematic evaluation of spliced alignment programs for RNA-seq data
• Reproducibility of high-throughput mRNA and small RNA sequencing across laboratories
• RNA Sequencing and Analysis
• STAR: ultrafast universal RNA-seq aligner
• Near-optimal probabilistic RNA-seq quantification

Genetic variation and genetic diversity

• Finding the missing heritability of complex diseases
• Molecular quantitative trait loci
• Structural racism and health inequities in the USA: evidence and interventions
• Genomics of disease risk in globally diverse populations
• The missing diversity in human genetic studies
• Evaluating the promise of inclusion of African ancestry populations in genomics
• The Genetic Structure and History of Africans and African Americans

Statistics

• False discovery rates: a new deal
• Fine-mapping and QTL tissue-sharing information improves the reliability of causal gene identification
• Fine-mapping from summary data with the “Sum of Single Effects” model
• Flexible statistical methods for estimating and testing effects in genomic studies with multiple conditions
• An Introduction to Empirical Bayes Data Analysis
• Inference of Population Structure Using Multilocus Genotype Data: Linked Loci and Correlated Allele Frequencies
• Bayesian statistical methods for genetic association studies
• A Statistical Framework for Joint eQTL Analysis in Multiple Tissues
• Principles of statistical genomics (book)

Training Basics

This basic training includes programming, record-keeping, and institutional compliance. This is listed in order of importance.

Upcoming workshops at Northwestern: workshops.

Northwestern also has access to LinkedIn Learning.

Compliance training

• Harassment training
• Environmental health and safety
• Human subjects
• Patient privacy

Linux and bash

• Linux essentials
• The Unix Workbench by Sean Kross
• Linux file permissions
• Shell (bash)
• sed and awk

Version Control

• About version control
• About git
• git to know git: an 8-minute introduction from the LIBD Rstats blog by Amy Peterson
• Version Control with Git
• Commit together with co-authors
• Closing issues using keywords
• Merging a pull request
• Syncing a fork
• General Guides

Text editors

• Visual Studio Code
• Markdown
• Org Mode with Emacs
• GNU Emacs
• LaTeX
• Learning LaTeX in 30 minutes

Configure R in VS Code on NSF ACCESS Bridges-2

To configure VS Code to use R from a Conda environment, open the Command Palette (Cmd+Shift+P on macOS or Ctrl+Shift+P on Linux and Windows), then select Preferences: Open Workspace Settings (JSON).

Add the following settings, using the NSF ACCESS Bridges-2 paths for your Conda environment. For example, the rnaseq environment uses:

{
  "r.rpath.linux": "/ocean/projects/bio260021p/shared/opt/envs/rnaseq/bin/R",
  "r.rterm.linux": "/ocean/projects/bio260021p/shared/opt/envs/rnaseq/bin/R",
  "r.alwaysUseActiveTerminal": true
}

Replace rnaseq in both paths with the name of your environment, such as network or eqtl.

Open the Command Palette again and select Developer: Reload Window. After VS Code reloads, open the Command Palette and select R: Create R terminal.

Quarto

• Getting started
• Guides
  • Presentations
  • Publishing basics
  • All formats
• JupyterLab
  • Guide
  • Extension
• Gallery
  • Article
  • Presentation: Beamer
  • Presentation: RevealJS
  • Website
  • Python book

LabArchives

• YouTube Videos
• Getting started LabArchives
• LabArchives at Northwestern
• Markdown syntax
• Computational Research Example

Python programming

• Google’s Python Class
• Python on Kaggle
• JupyterLab Documentation
  • Get started
  • Example
  • Video: Lab vs notebook
• Polars for data frames
• Intro to machine learning
• CUDA with Rapids
• General Guides

R programming

• R/Bioconductor Data Science bootcamps
• Getting Started with R and RStudio
• R Reference Card
• Posit Cheatsheets
• General Guides

HPC cluster environment: QUEST

• QUEST
  • General Access
  • Genomics Compute Cluster
  • Connecting to Jupyter and RStudio
  • User Guide
  • QUEST Videos
• SLURM

Sign Up for NSF ACCESS and Bridges-2

NSF ACCESS provides access to Bridges-2 and other advanced computing resources. To join the lab’s existing ACCESS project:

1. Register for an ACCESS ID using your institutional email address. Your email domain must match the institution listed in your ACCESS profile.
2. Complete your ACCESS profile and record your ACCESS ID.
3. Send your ACCESS ID to Dr. Benjamin or the lab’s allocation manager so that you can be added to the project and its Bridges-2 resources. Do not request a separate allocation unless instructed to do so.
4. Check My Projects in the ACCESS Allocations portal to monitor your account status. New resource accounts may take several days to be provisioned.
5. Once access is active, find your Bridges-2 resource username under My Projects. This username may differ from your ACCESS ID. Follow the Bridges-2 documentation to set up your PSC credentials and log in.

The ACCESS new-user guide provides more information about accounts, projects, allocations, and resources.

Working in the HEART-GeN Lab

Expectations of Lab Members

What You Should Expect from Me as Principal Investigator

As the principal investigator (PI) of the HEART-GeN lab, my role is to lead our group and advance its research. In practice:

• I write grants to fund our work
• I manage, supervise, and provide timely feedback on
  • research activities
  • manuscripts
  • data management
• I initiate and manage collaborations to increase our research impact

In addition to this role, I am also your mentor. I am committed to helping every team member work toward their personal goals. My mentorship will be tailored to each individual. At the same time, everyone will learn or refine critical-thinking, management, and mentorship skills during their time in the HEART-GeN lab.

Tips for Working with Me:

• If I’m more than 5 minutes late to our scheduled meeting, please send a Slack message. I may have become distracted, but I haven’t forgotten!
• As a neurodivergent person, I may not make eye contact. Rest assured, I am still actively listening to you!
• There are times when I experience sensory overload. During these moments, I’ll wear noise-canceling headphones and keep my office door shut. If you have an urgent matter or a question during this time, please reach out to me via Slack.

What I Expect from Lab Members

I expect you to:

• Learn how to think critically
• Learn how to present and document your research findings to the community
• Be responsive to feedback
• Ask questions when you need clarification
• Treat lab members with respect
• Share your expertise with the team
• Come prepared to meetings
• Ask for help if you feel overworked or overwhelmed

Our lab thrives on a team of individuals who embody the following qualities:

• Passion and Dedication: We seek individuals with a strong commitment to addressing health disparities in neurological disorders. Your drive and enthusiasm will fuel our progress.
• Integrity and Transparency: Upholding scientific integrity is paramount. We value honesty, open communication, and a commitment to ethical research practices.
• Curiosity and Growth Mindset: We encourage a continuous learning environment. Your willingness to learn new skills, ask questions, and challenge the status quo will be a valuable asset.
• Collaborative Spirit: Science thrives on teamwork. You’ll be someone who enjoys working alongside others, fostering a supportive and productive lab environment.
• Reliability and Accountability: We value team members who consistently deliver high-quality work and take ownership of their responsibilities. You can be counted on to meet deadlines and follow through on commitments.

Record-Keeping

Computational research relies on clear and accurate documentation to ensure reproducibility and scientific progress.

• Dry-lab Work: Git and GitHub serve as our primary electronic lab notebook (ELN) system for dry-lab work. Documentation, code, workflows, and project notes must live in GitHub repositories. Version control is not optional; it is required for code and analysis history.
• Wet-lab Work: LabArchives is the primary ELN for tracking wet-lab experiments. It is also an optional secondary dry-lab notebook.

Standardized Format

In our group, all notebooks include standard sections: background, goal (objective and hypotheses), study design, methods, results (including negative or inconclusive), and interpretation. For computational projects, methods will include the general approach and associated code blocks. This also means including relevant figures and tables to illustrate your findings.

For record-keeping, we use text files written with a combination of Markdown, LaTeX, and Jupyter notebooks. This primarily is implemented with Quarto.

Using Electronic Lab Notebooks (ELNs)

Our group uses ELNs. This facilitates efficient data entry, organization, and collaboration. ELNs offer advantages such as version control, searchability, and accessibility from multiple devices.

Our lab uses LabArchives as our ELN system. Northwestern has an enterprise license so that all lab members can have a free account. Getting access and training is part of Onboarding. LabArchives is required for hybrid wet/dry trainees and serves as a secondary notebook for dry-lab work to capture project notes that live outside GitHub.

Document All Procedures and Protocols

Document all computational procedures, protocols, and scripts used in data analysis or software development. Include details such as parameter settings, software versions, and any modifications made during the process. We have specific code blocks for Python and R to help output session information, which will include software versions.

In our group, we document negative or inconclusive results, as they can be valuable for future research.

Record Data Inputs and Outputs

Record all data inputs and outputs generated during computational experiments or simulations. Document the source of input data, processing steps, and resulting outputs to ensure transparency and reproducibility.

Maintain Detailed Metadata

Include detailed metadata alongside computational datasets, specifying information such as experimental conditions, data sources, preprocessing steps, and quality control measures. This metadata enhances the understanding and usability of the datasets.

Implement Version Control Systems

Implement version control systems (e.g., Git) for managing code repositories and tracking changes in computational scripts and software. Regularly commit code updates and provide descriptive commit messages to facilitate collaboration and reproducibility.

Backup Data Regularly

We have regular backup procedures for computational data, code, and analysis results to prevent data loss in case of hardware failures or accidents. Lab data are backed up quarterly, but individual team members should regularly back up their work computers to the HPC.

Document Computational Workflows

In addition to individual project codes, we also generate computational workflows and pipelines used for data processing, analysis, and visualization. For all workflows and pipelines, a flowchart or diagram illustrating the sequence of operations and dependencies between different components should be created.

Ensure Data Security and Privacy

Adhere to data security and privacy regulations when handling sensitive or confidential information. Implement encryption, access controls, and other security measures to safeguard computational datasets and research findings.

Regularly Review and Validate Entries

We hold monthly code review sessions that are part of the entry validation process. This helps ensure that electronic records are accurate, complete, and consistent. Anyone can have a small bug in their code, so these sessions are part of our team’s peer-review and collaborative efforts to identify potential errors or discrepancies.

Provide Clear Attribution and Acknowledgment

Provide clear attribution and acknowledgment for all contributors to computational projects, including data providers, software developers, and collaborators. Acknowledge funding sources and grants that support the research. For example, if using a public dataset, make sure to include any needed acknowledgment in your notebook. For working with code in a Git repository, remember to fork the original repository to help keep track of attributions. This type of code notation will be part of your training.

Data

In our lab, we hold transparency, integrity, and collaboration as core values in data collection, management, and sharing. The following describe the expectations of all team members for data management. By adhering to the following expectations, we ensure responsible data management practices that contribute to the advancement of our research and foster a collaborative environment within the lab. If you have any questions or require further clarification, please don’t hesitate to discuss them with Dr. Benjamin.

Data Collection and Management

Documentation: Team members are expected to record all aspects of their data collection process, including methodologies, equipment, and data cleaning steps (Record-Keeping).

Metadata, File Naming, and Organization: Team members must create comprehensive metadata, including descriptions of data sources, variables, and preprocessing steps. File naming conventions should be clear, consistent, and descriptive to facilitate easy identification and retrieval of data. Organize data into logical folders and subfolders based on projects, experiments, or datasets.

Version Control: Adopt version control systems like Git for managing code scripts, analysis pipelines, and documentation. Team members are required to commit code updates regularly, provide informative commit messages, and maintain separate branches for development and production environments.

Data Storage and Security

Data Storage: Data should be stored securely in designated locations to prevent loss or unauthorized access. Team members are required to store their data on approved local platforms, including secure network drives or servers designated by the lab. Some team members will lead new data-processing efforts; in these cases, raw data must be stored in both local and cloud storage.

Data Backup: Regular and automated data backups are mandatory to safeguard against data loss. Team members must ensure that data backups are performed consistently and stored in secure locations.

Access Control: Access to lab data should be restricted to authorized personnel only. Team members are responsible for maintaining the confidentiality and security of lab data and should not share access credentials with unauthorized individuals.

Data Ownership and Access Upon Departure: Team members retain ownership of the data they generate during their tenure in the lab. Upon leaving the lab, individuals are expected to transfer ownership of their data to Dr. Benjamin or designated successor. Access to lab data will be revoked for departing members to maintain data security. However, anonymized datasets may be retained for future reference with Dr. Benjamin’s approval. Additionally, an agreement for secure data transfer can be arranged with a data use agreement.

Open-Access and Controlled-Access Data

Open-access data are available without individual authorization from a data access committee or data provider. Public availability does not eliminate all responsibilities. Licenses, terms of use, consent limitations, attribution requirements, and ethical obligations may still apply.

When working with open-access data:

• Confirm that the data are genuinely open access and review their license and terms of use before downloading or redistributing them.
• Record the repository, accession number or persistent identifier, version, download date, checksum when available, license, and required citation.
• Keep raw data read-only when practical and separate them from processed data, results, and code.
• Do not assume that a derived dataset is open access merely because one input was open. Combining open data with controlled, identifiable, or otherwise sensitive data may change the classification of the result.
• Continue to protect participant privacy. Public or de-identified human data should not be used to attempt re-identification.

Controlled-access data require approval before access and are governed by requirements such as a Data Use Certification (DUC), Data Use Agreement (DUA), Institutional Review Board (IRB) protocol, informed consent, repository policy, or institutional data security plan. Controlled-access data may remain sensitive even when direct identifiers have been removed.

The requirements of the applicable DUC, DUA, IRB protocol, data provider, and Northwestern policy supersede general guidance in this manual. Ask Dr. Benjamin and the appropriate institutional office when requirements are unclear.

General Practices for Controlled-Access Data

1. Obtain approval before access: Use data only for the approved research purpose and only after all required agreements, training, and institutional approvals are active. Only individuals named or otherwise authorized under those approvals may access the data. Never attempt to identify or contact participants unless the governing documents explicitly permit it and the required approvals are in place.
2. Classify the data and approve the environment: Before downloading data, document their classification and confirm the approved storage, compute, backup, and collaboration systems in the project’s data security plan. Do not assume that a personal computer, Quest, Bridges-2, GitHub, OneDrive, Dropbox, or any other service is approved. Some NIH controlled-access data have requirements that are not compatible with Quest without prior review. Contact Northwestern Research Data Services for guidance.
3. Limit access: Use individual accounts, multifactor authentication, and least-privilege permissions. Never share accounts or credentials. Maintain a current list of authorized users and promptly remove access when a person changes roles, leaves the project, or no longer requires the data.
4. Use approved storage and transfer methods: Keep controlled-access data only in approved locations and use approved encrypted transfer methods. Do not send data through email or Slack, create public or anonymous sharing links, place data in personal cloud storage, or use unapproved removable media. Avoid unnecessary local copies.
5. Protect the entire workflow: Treat raw data, temporary files, caches, logs, backups, intermediate files, and potentially identifying derived data as controlled until an authorized review determines otherwise. Do not combine controlled-access data with other datasets unless the approved use and agreements permit it.
6. Keep controlled data out of Git: Never commit controlled-access data, participant or sample identifiers, sensitive metadata, credentials, or revealing logs to GitHub – even in a private repository. Use synthetic or approved public example data in code and documentation. Review staged files and diffs before every commit; .gitignore is helpful but is not a security control by itself.
7. Review outputs before release: Do not move results out of the approved environment or share them externally until they have passed the required disclosure review. Follow project-specific rules for aggregation, small-cell suppression, figures, tables, model outputs, and other derived products. Obtain approval before using results in manuscripts, presentations, posters, or public repositories.
8. Document use and attribution: Record approvals, authorized users, dataset versions, accession numbers, analysis locations, transfers, renewals, expiration dates, and required acknowledgments. Cite and acknowledge the data generators, repository, accession numbers, and funding sources as required.
9. Retain or destroy data correctly: At the end of the approved period, follow the DUC, DUA, repository, and institutional requirements for renewal, return, archival, or verified destruction of all copies, including backups and intermediate files. Document completion.
10. Report incidents immediately: If controlled data are lost, exposed, sent to the wrong person, placed in an unapproved location, or accessed by an unauthorized person, stop further transfer or sharing and notify Dr. Benjamin and Northwestern IT immediately. Do not delete or alter potential evidence unless instructed. Follow all additional reporting requirements in the DUC, DUA, IRB protocol, and repository policy. See Northwestern’s information security incident instructions or email security@northwestern.edu.

Review the NIH Genomic Data User Code of Conduct, NIH Security Best Practices for Controlled-Access Data, Northwestern guidance for protecting sensitive research data, and Quest data security guidance before working with controlled-access data.

Data Ownership and Sharing

Transparent Data Sharing: Transparent data sharing within the lab, particularly with Dr. Benjamin, is essential for fostering collaboration and ensuring research integrity. All team members are expected to share their data with Dr. Benjamin regularly and proactively, providing updates on progress, challenges, and findings (see Meetings in the Lab).

Data Use Agreements (DUAs): For collaboration outside the lab, DUAs should be established outlining permitted uses and attribution requirements. In turn, we must also comply with any DUAs associated with external datasets or collaborations. Before accessing or using external data sources, team members are responsible for reviewing and adhering to the terms and conditions specified in the DUAs. Any questions or concerns regarding DUAs should be addressed with Dr. Benjamin or the team member’s designated supervisor. Our lab maintains a list of external data with DUAs attached to help with this.

Long-Term Archiving: We deposit anonymized data in public repositories following institutional policies, ensuring long-term accessibility for future research. Team members should consult with Dr. Benjamin or a designated data steward to determine the most suitable archiving platform and procedures for their datasets.

Data Management Tools and Practices

Electronic vs. Physical Documents: Whenever possible, team members should prioritize electronic documentation (e.g., LabArchives) over physical documents to facilitate accessibility, sharing, and version control. Physical documents should be digitized and uploaded to LabArchives.

Data Visualization Tools: Data visualization tools enable our team to explore, analyze, and communicate research findings effectively. Visualization software such as matplotlib (Python) or ggplot2 (R) can be used to create informative graphs, charts, and interactive dashboards (plotly or shiny) for presenting data insights. Our use of ELNs and Jupyter means that visualization is built within our notebooks.

Collaboration and Communication Tools: Collaboration and communication tools such as Slack or Zoom facilitate real-time communication and project coordination among team members. In addition to these tools, we use GitHub issues to monitor project milestones, including project coordination, management, and communication. Team members should use these tools in addition to LabArchives to streamline collaboration, exchange ideas, and coordinate research activities effectively.

Training and Support: Team members will receive training and support in using data management tools effectively. The lab will provide resources, workshops, and documentation to familiarize team members with the tools and practices adopted by the lab, enabling them to harness the full potential of these tools in their research endeavors.

Professional Development

Our lab is committed to supporting your professional development and career goals. We recognize the importance of continuous learning and skill development for success in research. We expect all team members to actively pursue professional development throughout their time in the lab. This could involve attending workshops, seminars, or conferences relevant to your goals.

Individual Development Plans

An Individual Development Plan (IDP) serves as a personal strategic roadmap for achieving job-related, career-oriented, and professional development goals. IDPs are valuable career resources that help team members map their career trajectories and take crucial initial steps toward their goals.

The IDP has five steps:

1. Define career objectives and competencies: This means identifying a career path by exploring different job options. In doing so, you can get a list of skills needed to achieve that goal.
2. Self-assessment to identify areas of growth: Evaluate current strengths and areas for improvement.
3. Identify training gaps: What is missing from your experience and training?
4. Set achievable goals: Make concrete plans to improve your skills with short- and long-term career goals.
5. Monitor, assess, and adapt the IDP: Regularly review and update the IDP to reflect progress, changing circumstances, and evolving career aspirations.

Create your IDP at http://myidp.sciencecareers.org.

Scientific Writing

Scientific writing is a lifelong journey of improvement. As such, our lab prioritizes continued education on scientific writing. This includes hosting a weekly writing accountability group (WAG) for the lab. All trainees will be expected to attend at least one scientific writing workshop and/or course. Additionally, a writing session will be organized as part of our annual retreat.

Books in the lab:

• On Writing Well: The Classic Guide to Writing Nonfiction
• The Scientist’s Guide to Writing
• How to Write and Publish a Scientific Paper
• The Elements of Style

Abstract Writing

• Identifying and Prioritizing Elements of a Research Abstract (Northwestern University)
• Abstracts (UNC Writing Center)
• Components of a Competitive Abstract (ABRCMS)
• ASM abstract-writing course

Paper Structure

• Scientific Writing (UNC Writing Center)
• Ten Simple Rules for Structuring Papers (PLOS Computational Biology)

1. Publications

   • Successful Scientific Writing and Publishing
   • Resources for Authors (BMJ)
   • Author Resources (Nature Journal)
   • Publication Figures
   • Open Access
   • Springer Notes
     • Research question
     • Structure
     • Title, Abstract, Keywords
     • Introduction, Methods, Results
     • Discussion and Conclusions
     • Figures and tables
     • Acknowledgments and References

2. Grant Writing

   • NIH applications
   • NIH Grant Tutorials
   • Grant Proposal
   • Grant figures
   • NIH Boot Camp

Science Communication

As part of all team members’ development, Dr. Benjamin will host an annual presentation workshop tailored to the team’s composition. It will always include poster presentations (i.e., 60 seconds, 5 minutes, or 15 minutes) and oral presentations (i.e., 3 minutes, 10 minutes, or 45 minutes). It may also include job talks and general science communication.

Before any major presentations, team members will be expected to practice with Dr. Benjamin during a one-on-one meeting, followed by at least one group practice during the weekly team meetings.

1. Scientific Presentation Resources

   Dr. Benjamin is always available to help with presentations. Below are some additional resources.

   • Ten simple rules for effective presentation slides
   • Ten simple rules for poster presentations
   • Ten simple rules for oral presentations
   • NIH Science Communication Workshops

2. Beamer Resources

   Dr. Benjamin uses LaTeX Beamer for presentation slides and posters.

   • Tutorial Slides
   • User guide
   • Overleaf documentation - Beamer
   • Overleaf documentation - Posters

Conferences

Attending conferences may be an essential component of a team member’s professional development. Depending on the location, national conferences can be expensive to attend. All team members can expect Dr. Benjamin to seek funding for them to attend one national conference every two years. This may include leveraging university or departmental resources. Therefore, it is important that team members identify conferences at their annual performance review to plan accordingly. Dr. Benjamin encourages attending local conferences annually as part of scientific communication training.

1. Local

   1. Chicago’s Premier Undergraduate Research Symposium (April)
   2. Undergraduate Research & Arts Expo (May)
   3. Annual Lewis Landsberg Research Day (September)
   4. Simpson Querrey Institute for Epigenetics Symposium (October)

2. National and Regional

   There are a number of conferences that may be appropriate for a given trainee. Below is a list of conferences that Dr. Benjamin often attends. This is not a comprehensive list of conferences, but a starting place for selecting national conferences to attend.

   1. American Society of Human Genetics (ASHG)
   2. CSHL Biology of Genomes or Biological Data Science
   3. Society for Neuroscience (SfN)
   4. Annual Biomedical Research Conference for Minoritized Scientists (ABRCMS)
   5. Society for the Advancement of Chicanos/Hispanics and Native Americans in Science (SACNAS)

   Other conferences that are related to our work include:

   1. World Congress of Psychiatric Genetics (WCPG)
   2. American Psychiatric Association (APA)
   3. International Society for Computational Biology (ISCB)
   4. NeurIPS, Annual Conference on Neural Information Processing Systems

HEART-GeN Lab Policies

Work Hours

We balance productivity, well-being, and flexibility while ensuring that essential tasks are completed in a timely manner. As such, we have a hybrid, flexible policy.

Core Hours: Team members are expected to be available for collaborations, meetings, and communications from 0900 to 1800. This may depend on team dynamics and project requirements (i.e., a collaborator in a different time zone). In general, team members can expect Dr. Benjamin to communicate during these core hours. Full-time staff should plan to work from the office at least three days per week.

Flexible Schedule: We offer flexibility in work hours to accommodate individual preferences and personal commitments, such as family obligations or commute constraints. Schedules are adjustable as long as team members meet their work responsibilities and communicate effectively with other team members.

Expected Work Hours: In academia, the hours needed to complete projects will ebb and flow. To promote a healthy work-life balance and prevent burnout, full-time team members are encouraged to work no more than 160 hours a month. While this is roughly 40 hours a week, the allocation of these hours is flexible. Undergraduate and high school team members should work no more than 10 hours a week during the school year.

Remote Work Options: We embrace remote work as a primarily computational lab. Monday is our official work-from-home day. A full in-person work day consists of at least four hours in the office.

Fully Remote Team Members: Fully remote team members are expected to attend the annual lab retreat. The lab will provide travel and accommodations.

Breaks and Rest Periods: It is important to take regular breaks and rest periods throughout the workday to prevent fatigue and maintain productivity. Please remember to step away from your screens, stretch, and recharge periodically – every hour if you can manage it.

Monitoring and Support: We provide support and resources to help our team members manage their workloads effectively. This includes regularly monitoring work hours, workload distribution, and individual well-being to identify any signs of excessive stress or overwork. Please do not hesitate to use a personal/mental health day when you need one.

Feedback and Evaluation: This is a working policy. As such, we will continuously evaluate its effectiveness with regard to team members’ work hours, schedule flexibility, and overall satisfaction with the policy. We will use this feedback to refine and improve the work hour policy to better meet the needs of the team.

Time Off

In our lab, open communication and mutual respect are fundamental principles when requesting time off. Here’s how team members should inform Dr. Benjamin about their need for time off:

Notification Process: Team members should notify Dr. Benjamin of their intention to take time off as soon as they become aware of the need. While emergencies may necessitate immediate communication, for planned time off, team members should aim to provide notice well in advance to allow for proper planning and coordination.

Preferred Channels: Lab members can inform Dr. Benjamin of their time-off requests through a variety of communication channels, including email or Slack. Slack is recommended for both time-off requests and additional work-from-home requests. An in-person communication should be followed by either an email or Slack message for Dr. Benjamin’s records. Regardless of the communication method, clarity and professionalism are expected.

Expectation of Time Away: Team members are encouraged to take time away from the lab as needed to prioritize their well-being, personal obligations, and professional development. The lab culture supports a healthy work-life balance, and members should feel empowered to take time off when necessary without fear of judgment or reprisal.

Flexibility and Understanding: Dr. Benjamin understands that unforeseen circumstances may arise, and team members may need to adjust their schedules or take time off on short notice. While advance notice is preferred, Dr. Benjamin is committed to being flexible and accommodating when feasible, provided that lab activities can continue smoothly and deadlines can be met.

Requests to Postpone Time Off: While Dr. Benjamin recognizes the importance of taking time off for self-care and personal responsibilities, there may be instances where urgent deadlines, critical experiments, or team commitments necessitate the postponement of planned time off. In such cases, Dr. Benjamin will communicate openly with team members, explaining the rationale behind the request to defer time off and seeking to find mutually acceptable solutions.

Planning Ahead: To ensure that lab activities can continue smoothly during a member’s absence, Dr. Benjamin encourages team members to plan ahead and delegate tasks or responsibilities as necessary. By proactively identifying potential bottlenecks or dependencies in projects, team members can minimize disruptions and facilitate a seamless transition during their time away.

Setting a Tone of Self-Care: Dr. Benjamin strives to set a positive tone around the importance of self-care and work-life balance. By modeling healthy behavior and prioritizing his own well-being, Dr. Benjamin aims to create a supportive and inclusive environment where team members feel valued, respected, and empowered to prioritize their own needs.

In summary, team members are encouraged to communicate openly and proactively about their time-off needs, with advance notice preferred whenever possible. While taking time off is encouraged, there may be instances where flexibility is required to accommodate urgent lab needs. Through open communication, understanding, and mutual respect, we can foster a culture of well-being and productivity in our lab.

Code of Conduct

In our lab, we uphold a code of conduct to maintain a safe, respectful, and productive work environment. While some expectations may seem implicit, it’s essential to make them explicit to ensure clarity and consistency across the team.

This Code of Conduct is a living document and may be subject to revision as needed. We believe that by adhering to these principles, we can create a thriving research environment that fosters innovation, collaboration, and ethical research practices.

Here are the expectations regarding various aspects of lab conduct.

1. Professionalism and Collaboration

   Respectful Communication: Treat all members of the group with respect, courtesy, and inclusivity. Engage in constructive criticism and maintain a professional tone in all communications. This means avoiding discriminatory or offensive language, behavior, or jokes that may create a hostile or unwelcoming environment.

   Open Communication and Transparency: Share ideas, data, and progress updates openly with the group. Promote transparency in research methodologies and findings. Acknowledge and respect the intellectual contributions of others, including collaborators, mentors, and research participants.

   Collaboration and Teamwork: Work collaboratively with team members to achieve common goals. Be open to sharing expertise and assisting others. Communicate openly and honestly with team members and collaborators, providing timely updates on progress, challenges, and results. Listen actively and respectfully to others’ viewpoints, seeking to understand diverse perspectives and foster constructive dialogue.

2. Research Integrity and Reproducibility

   Responsible Data Management: Adhere to best practices for data collection, management, and documentation as outlined in our lab data management plan. Protect sensitive or confidential information from unauthorized access, disclosure, or misuse, maintaining data security and privacy at all times.

   Code Sharing and Documentation: Share computational code with fellow researchers and document your code clearly to ensure reproducibility.

   Responsible Authorship: Authorship will be determined by significant contributions to the research project. All contributors should be appropriately acknowledged.

   Honest Research Practices: Conduct research with honesty and integrity. Report any observed instances of research misconduct, such as fabrication, falsification, or plagiarism (Honesty and Objectivity).

3. Responsible Use of Resources

   Efficient Use of Computational Resources: Use computational resources responsibly and efficiently. Avoid wasteful practices and be mindful of shared resources.

   Software Licensing: Comply with software copyrights and licenses. Use software only for its intended purpose.

   Open Source Contribution: Contribute to open-source software projects where relevant and appropriate.

4. Reporting Concerns

   Open Communication of Issues: If you experience or witness any form of discrimination, harassment, bullying, or unethical research practices, feel empowered to voice your concerns directly to Dr. Benjamin or another trusted member of the group. Anonymous reporting mechanisms may also be available.

5. Continuous Learning and Development

   Professional Growth: Continuously seek opportunities to learn new skills and stay updated with advancements in computational research methods and tools.

   Mentorship and Knowledge Sharing: Be willing to mentor others and share your knowledge to foster a culture of learning and development within the group.

6. Adherence to Institutional Policies

   Compliance with Regulations: All research activities will be conducted in accordance with institutional policies and regulations, including those related to data privacy, ethical research practices, and responsible conduct of research (RCR).

7. Resources

   • Institutional codes of conduct and policies
   • Graduate student codes of conduct
   • Employee codes of conduct
   • Research integrity policies
   • Responsible Conduct of Research
   • Office of International Student and Scholars

Performance Reviews

Our lab prioritizes continuous feedback and professional development for all team members. We recognize that research trainees and staff have different needs and timelines, so we use different approaches to performance reviews.

1. Postbaccalaureate, Graduate, and Postdoctoral Trainees

   Research trainees include postbaccalaureate (postbacs), graduate students, and postdoctoral fellows.

   Frequency: We conduct formal reviews at least annually, often coinciding with a trainee’s thesis committee meeting or annual Individual Development Plan review. This is adjusted for each trainee based on their Mentoring Agreement.

   Format: Reviews will involve a discussion based on your IDP goals, progress made, and any areas requiring further development. We may also include program-specific review forms, depending on departmental requirements. Prior to scheduling committee meetings, all trainees will have a one-on-one meeting dedicated to reviewing progress and professional development.

   Criteria: Reviews will focus on research progress, publication record, scientific communication skills, laboratory skills, scientific writing skills, and trainee-specific professional development goals.

   Who Conducts Reviews: Dr. Benjamin will conduct initial reviews alone. Other committee members will conduct a separate review during thesis committee meetings.

2. Undergraduate and High School Trainees

   Undergraduate and high-school research trainees will have annual or seasonal performance reviews.

   Summer trainees: For trainees who are with the lab for a summer, Dr. Benjamin will conduct a review during the exit interview (see Leaving the Lab). This informal review tracks research progress, scientific communication and writing skills, and trainee-specific professional development goals.

   Undergraduate trainees: Dr. Benjamin will conduct a review after every academic semester. This formal review tracks research progress, scientific communication and writing skills, computational skills, and trainee-specific professional development goals.

   High school trainees: Dr. Benjamin will conduct a quarterly review (every three months). This informal review tracks research progress, computational skills, scientific communication, and trainee-specific professional development goals.

3. Lab Staff

   Frequency: Formal reviews will be conducted annually, following institutional policies and procedures. These reviews typically occur around the anniversary of the employee’s start date.

   Format: Reviews will use the standard university staff performance review form. The review process will include a combination of self-assessment, supervisor evaluation, and input from peers and collaborators that interact with the team member on a regular basis.

   Criteria: Performance criteria for university employees may be based on job responsibilities, key performance indicators, and competencies outlined in the standard performance review form provided by the university. These criteria often include areas such as job knowledge, quality of work, communication skills, teamwork, and professional development.

   Who Conducts Reviews: Dr. Benjamin will conduct reviews, potentially in consultation with other team members who work closely with the staff member being reviewed.

4. Additional Considerations

   In addition to the performance reviews above, team members will receive regular weekly input and feedback on their work and progress during One-on-One Individual Meetings. Furthermore, reviews are additional opportunities to discuss training needs and opportunities for skill development.

AI/ML and Generative AI (LLMs) in the Lab

Our lab uses computational methods, including machine learning, in our research. We also recognize that generative AI tools (e.g., large language models/LLMs) can be useful in limited contexts. Our goal is to foster responsible, ethical, and transparent use that protects research integrity, privacy, and reproducibility.

Scope: These expectations apply to generative AI/LLM tools used for writing, code assistance, troubleshooting, or figure and visual-content generation. Use of conventional ML methods as part of research (e.g., training models, statistical learning) is covered by standard scientific and reproducibility practices.

Practical expectations include:

• PI guidance supersedes: Dr. Benjamin’s instructions about AI/LLM use for a project or role override general guidance in this manual.
• Training/learning (no AI): When you are learning core skills (coding fundamentals, statistics, pipelines, tooling, or lab workflows), do not use AI/LLMs. Learning in this lab must be done through documentation, course material, mentors/peers, and your own problem-solving. If you are unsure what counts as “learning,” assume AI is not permitted and ask Dr. Benjamin.
• Project use: AI/LLM use is not the default in research projects. If AI is permitted for a project, it must be pre-scoped to a narrow, specific task approved by Dr. Benjamin (e.g., clarifying an error message or pointing to documentation). Broad or open-ended use (e.g., “help me write this,” “debug my pipeline,” “improve this code,” “make a figure”) is not allowed without explicit approval.
• Coding assistance: Unless explicitly approved by Dr. Benjamin, AI/LLMs may not be used for coding, except for debugging. Debugging means: diagnosing and correcting errors in code you already wrote and understand, limited to small, isolated snippets tied to a specific error message. Debugging does not include generating new code, rewriting/refactoring, optimization, designing workflows, feature implementation, or translation between languages.
• Manuscripts and figures: Do not use AI/LLMs for manuscript or grant writing, or for generating figures/visualizations, unless Dr. Benjamin explicitly authorizes a specific narrow use, such as copy editing or brainstorming.
• Disclosure: Always document when text, code, analyses, or figure elements were generated or materially modified using an AI/LLM.
• Accountability: Researchers remain fully responsible for all AI/LLM-assisted outputs (correctness, originality, citations, and compliance).
• Privacy/compliance: Do not enter sensitive, confidential, controlled-access, or identifiable data into external AI/LLM services. When in doubt, ask first.
• Privilege: Permission to use AI/LLMs is a discretionary privilege and may be revoked by Dr. Benjamin with or without notice.

1. Choosing AI/ML Tools

   Alignment with Research Goals: AI/ML tools should be selected based on their suitability to address specific research questions and objectives.

   Transparency and Explainability: Give preference to AI/ML tools with transparent algorithms or mechanisms that allow for understanding the rationale behind model outputs.

   Bias Considerations: Be mindful of potential biases present in AI/ML algorithms and datasets used during research. Implement strategies to mitigate bias where possible.

   Security and Privacy: Choose AI/ML tools that meet appropriate security standards and prioritize data privacy.

2. Responsible AI/ML Research Practices

   Data Quality: Ensure the quality and relevance of data used for training and evaluating AI/ML models. Address issues of data completeness, accuracy, and potential biases.

   Documentation and Code Sharing: Document AI/ML workflows thoroughly, including code, training procedures, and model hyperparameters. Consider sharing code openly when possible to facilitate reproducibility and collaboration.

   Model Validation and Testing: Rigorously test and validate AI/ML models to assess their performance, limitations, and potential for generalizability.

   Interpretation and Context: Interpret outputs of AI/ML models critically, considering their limitations and potential for errors. Provide appropriate context for AI/ML-generated findings within the overall research framework.

   Ethical Considerations: Be mindful of the ethical implications of AI/ML research. Consider potential societal impacts and unintended consequences of AI/ML applications.

3. Responsible Authorship and Credit

   Attribution: Clearly define the role of AI/ML tools within the research process. Acknowledge contributions of both AI/ML algorithms and the researchers who developed or applied them.

   Authorship: Assign authorship based on significant contributions to the research project. Researchers who develop, train, or interpret AI models should be appropriately recognized. AI does not meet our requirements for authorship, given the need for accountability. AI and LLM tools may not be listed as an author on any of our scholarly work. AI and LLM tools must be acknowledged if used to generate figures or in the writing process. Team members using AI and LLM tools are accountable for the accuracy, integrity, and originality of their work.

4. Communication and Reporting

   Transparency: Be transparent about the use of AI/ML in research projects. Communicate limitations and uncertainties associated with AI/ML models.

   Public Communication: When communicating research findings derived from AI/ML, clearly explain the role of AI/ML and its limitations to avoid misleading interpretations.

5. Responsible Use of AI Resources

   Computational Resources: Use computational resources efficiently when using AI/ML models. Explore options for reducing resource consumption where possible.

   Open Source Contribution: Consider contributing to open-source AI/ML frameworks and datasets whenever feasible.

   Software Licensing: Comply with all software licensing terms and conditions when using AI/ML tools.

6. Monitoring and Review

   Updating Policy: This policy will be reviewed and updated periodically to reflect advancements in AI/ML technology and evolving best practices.

   Reporting Concerns: If a team member has any concerns regarding the use of AI/ML within the research group, please inform Dr. Benjamin.

Leaving the Lab

As a member of the HEART-GeN lab, Dr. Benjamin strives to create a supportive and enriching environment where team members can thrive and achieve their scientific goals. As part of that process, team members may eventually move on to pursue exciting new opportunities. While Dr. Benjamin hopes that departures are primarily voluntary and planned, he understands that members may need to leave involuntarily. This policy outlines expectations for both planned and unforeseen departures.

1. Planned Departures

   Graduations: For students graduating, please inform Dr. Benjamin of your expected departure date well in advance. This discussion will be monitored during one-on-one meetings as part of professional development.

   Voluntary Separation: If you decide to leave the lab for another position, please give Dr. Benjamin at least six weeks’ notice. This notice allows time to manage projects and publications.

2. Unforeseen Departures

   In the rare event that a team member needs to be asked to leave the lab involuntarily, it will be done with careful consideration and in accordance with established procedures. This could be due to:

   Performance or Behavior Issues: Performance or behavioral concerns will be addressed directly with the team member by Dr. Benjamin. A corrective action plan will be developed, and if concerns are not addressed, involuntary departure may be necessary. This decision will be based on documented instances of performance or behavior issues that have been discussed with the member and have not been resolved.

   Project Funding: Research funding can sometimes end unexpectedly. In such circumstances, Dr. Benjamin will make every effort to place you in another research opportunity within the lab or connect you with alternative research positions. However, if no suitable options are available, involuntary lab departure due to funding limitations may be necessary. Dr. Benjamin will give four months’ notice if possible in this situation.

   Annual Renewal: Staff positions are renewed annually; at least five weeks’ notice will be given if a position is not renewed because of funding limitations or unresolved concerns following a corrective action plan.

3. General Considerations

   Data and Records: While the goal at the HEART-GeN lab is to keep well-organized data, research data and protocols should be up to date in LabArchives one month before a planned departure. Additionally, Dr. Benjamin will schedule extra meetings to ensure proper archiving and handover of project materials.

   Ongoing Projects: Ongoing projects will be discussed with Dr. Benjamin and other team members to determine the best course of action for completion or continuation.

   Publications: Prepare to continue collaborating with Dr. Benjamin and your co-authors to complete submissions of any manuscripts in progress. The goal for all trainees is to have first-author manuscripts submitted before departure.

   Communication: Open and transparent communication is key. Please discuss any questions or concerns regarding your departure from the lab with Dr. Benjamin as soon as possible. The more notice you give, the better, as Dr. Benjamin may be able to offer career advancement within the HEART-GeN lab or help identify external career opportunities. When you succeed, the HEART-GeN lab succeeds.

Troubleshooting and How to Get Help

Making and Disclosing Mistakes and/or Problems

Mistakes happen. What matters is how we respond to them. In the HEART-GeN lab, we value a culture of open communication and believe that disclosing mistakes, even difficult ones, is important for ensuring scientific integrity.

Making Mistakes

Everyone makes mistakes, including Dr. Benjamin! The important thing is to learn from them and take steps to prevent them from happening again. If you make a mistake, don’t panic!

1. Take a Breath and Assess: Take a moment to compose yourself and assess the situation. Consider the potential impact of the mistake.
2. Stabilize the Situation: If possible, take steps to prevent the mistake from causing further problems.
3. Get Help: Don’t hesitate to seek help from Dr. Benjamin or another team member with experience. We are here to support each other.
4. Address Mistake: Address any immediate consequences of the mistake. This might involve re-running code or documenting the error.
5. Disclose the Mistake: Come forward and honestly explain the mistake to Dr. Benjamin as soon as possible. Transparency is key to maintaining trust and taking corrective steps.
6. Learn and Teach: We’ll analyze the mistake together to understand what went wrong and how to prevent it from happening again. We will share this learning experience with the team to benefit everyone.

Problems Happen (Not Necessarily Mistakes)

Sometimes, problems happen that aren’t anyone’s fault. For example, a software version change may break a computational pipeline, or an update on the computing cluster may unexpectedly interrupt an analysis. The key is to communicate and collaborate to find solutions. If a problem happens, you can follow the above steps (2-6) to help troubleshoot.

Resolving Conflicts (with peers or PI)

Conflicts also happen! Working closely with diverse personalities and perspectives can sometimes lead to disagreements. Even so, conflict does not need to be a negative force. When handled constructively, it can spark creativity and lead to better outcomes.

Conflict in the lab

It’s Inevitable: We all have different backgrounds, work styles, and approaches. Disagreements are bound to happen, and that’s okay.

Focus on Solutions: The key is to focus on finding solutions rather than dwelling on the problem itself. Approach conflict as an opportunity to learn from each other and improve communication.

Diversity is a Strength: Remember that our lab thrives on the unique perspectives and skills each team member brings. Embrace these differences and see them as assets to overcome challenges and achieve better results.

My Expectations for Conflict Resolution

Open Communication: The most important tool for resolving conflict is clear and respectful communication. Actively listen to each other’s viewpoints and express your own concerns constructively.

Focus on the Issue: Keep the discussion focused on the specific issue at hand, avoiding personal attacks or blame games.

Willingness to Compromise: Be prepared to find common ground and explore solutions that work for everyone involved.

Seek Help if Needed: If you’re struggling to resolve a conflict with a team member, don’t hesitate to come to Dr. Benjamin for guidance or mediation.

Conflict Resolution Strategies

Here are some strategies that can be helpful when navigating conflict:

Schedule a Calm Discussion: Take some time to cool down before addressing the issue. Schedule a dedicated time to talk things through calmly and rationally.

Active Listening: Truly listen to the other person’s perspective without interrupting. Try to understand their concerns and motivations.

“I” Statements: Use “I” statements to express your feelings and needs without placing blame. For example, “I feel frustrated when…” instead of “You always…”

Brainstorm Solutions: Work together to brainstorm potential solutions that address everyone’s concerns. Be open to creative approaches.

Remember, conflict can be a catalyst for positive change. By following these principles and practicing open communication, we can effectively navigate disagreements and build a more cohesive and productive team.

How to Ask for Coding-Related Help

In general, please follow the Bioconductor composing guidelines when asking for help online.

Avoid Screenshots – Use Text

While a screenshot can contain a lot of information, it can make it difficult to extract the information needed to troubleshoot the problem.

Benefits of Text:

• Clarity and Precision: Text allows for clear and precise descriptions of the error, pinpointing the exact issue you’re facing.
• Copy-Pasting Relevant Code: Code snippets can be copied and pasted directly into error reports, allowing others to reproduce the problem.
• Searchability: Text is searchable, making it easier for others to find solutions to similar errors in the future.

What to Include:

• A clear and concise explanation of the error message or unexpected behavior you encountered.
• Steps taken that led to the error.
• Relevant code snippets or configurations involved.
• Any error messages displayed verbatim.

Resources

• Ombudsperson
• Graduate student union
• Northwestern University Postdoctoral association (NUPA)
• Title IX
• Counseling services

Responsible Conduct of Research

The Responsible Conduct of Research (RCR) is fundamental to the integrity and success of scientific inquiry. As members of the scientific community, it is our collective responsibility to uphold the highest standards of ethics, professionalism, and integrity in all aspects of research. This section outlines the core principles and practices that govern our conduct within this laboratory.

Core Principles

Honesty and Objectivity

We strive to report data accurately and objectively, avoiding bias or the manipulation of results. We are committed to providing a truthful representation of our research findings (i.e., avoiding falsification, fabrication, or plagiarism).

1. Falsification

   Falsification entails altering or withholding research results (data) to support assertions or hypotheses. This can involve manipulating research instruments, materials, or procedures. Additionally, falsification encompasses distorting data through the manipulation of images or representations, including overinterpreting the data.

   To avoid this, our lab writes all code in scripts and shares it through GitHub. Furthermore, all original images must be archived for lab access.

2. Fabrication

   Fabrication involves creating or adding data, observations, or descriptions that did not genuinely arise during data collection or experimentation. For instance, it can happen when inventing additional experimental runs. It is crucial that claims about results are supported by complete datasets. Making claims based on incomplete or assumed results constitutes a form of fabrication.

   To avoid fabrication, our lab keeps documentation of all raw and processed datasets (see Data Management). During lab code review sessions, all team members will review the methods underlying the data. This will help prevent accidental data fabrication due to code errors.

3. Plagiarism

   Plagiarism is one of the most prevalent forms of research misconduct. It’s essential for researchers to diligently cite all sources and maintain meticulous notes. Using or presenting the work of others as one’s own, even inadvertently, constitutes plagiarism. Moreover, when reviewing privileged information, such as grants or journal article manuscripts for peer review, researchers must acknowledge that such material cannot be employed for personal use until it is published or publicly accessible and thus cannot be cited.

   To help with this, our lab uses Zotero as a citation manager. Getting access to the citation manager is part of Onboarding.

Data Management

Accurate and reliable data are the foundation of scientific inquiry. All research data (raw and processed) will be meticulously documented, organized, and stored securely. This includes code for processing the data with detailed protocol documentation.

Experimental protocols will be described in the Methods sections of our publications, shared through GitHub, and published in detail through online platforms (i.e., protocols.io, SciCrunch, or Nature Protocols) to facilitate transparency, reproducibility, and the verification of findings by others.

To facilitate the reprocessing of raw data, we will share the developed pipelines on GitHub and Zenodo, along with the software versions used (as detailed in each manuscript’s Methods section). All software will be accessible on GitHub and Zenodo, with Python tools additionally available on PyPI and R tools on R/Bioconductor. These resources will be accessible for download upon the initial manuscript submission. Cloud-based tools, including Terra and Research Workbench, will be employed for efficient data manipulation.

Authorship

Authorship will be assigned based on contributions to the research project. For our lab, we determine the project lead or leads – first author or co-first authors – at the start of every project. Every three months, authorship will be adjusted based on contributions. For formal evaluation, this will be cross-referenced with the project’s GitHub repository activity and the anonymous quarterly project progression survey.

Guidelines:

1. All persons designated as authors should qualify for authorship, and all those who qualify should be listed.
2. Authorship credit for original, research-based works (in any medium) may be based on:
   1. substantial contributions to conception and design, or acquisition of data, or analysis and interpretation of data;
   2. drafting the article or revising it critically for important intellectual content;
   3. sufficient participation in the work to take public responsibility for appropriate portions of the content;
   4. final approval of the version to be published.
3. Acquisition of funding, collection of data (for example, from a fee-for-service core facility), or general supervision of the research group (e.g., by former or current mentors not directly involved in the conception or execution of the publication), alone, does not justify authorship.
4. Financial and material support should be disclosed.
5. "Ghost-writing," a practice whereby a commercial entity or its contractor writes an article or manuscript and a scientist is listed as an author, is not permissible. Making minor revisions to an article or manuscript that is ghost-written does not justify authorship.
6. AI-generated text or copyediting must be disclosed in the acknowledgments.
7. Copy editors must be included in the acknowledgments.

Our lab uses an authorship rubric to help determine authorship and author order. This rubric is used at the end of the project when preparing a paper for submission.

Our authorship policy follows the ICMJE (International Committee of Medical Journal Editors) recommendations: https://www.icmje.org/icmje-recommendations.pdf

Conflicts of Interest

Public trust in the scientific process hinges, in part, on the transparent handling of our relationships and activities throughout the research lifecycle – from planning and implementation to writing, peer review, editing, and publication. The potential for conflicts of interest and bias arises when professional judgment concerning a primary interest, such as patient welfare or research validity, may be influenced by secondary interests, like financial gain. Perceptions of conflict of interest are as significant as actual conflicts.

Disagreements may arise regarding whether an author’s relationships or activities constitute conflicts. While the presence of such relationships doesn’t necessarily indicate problematic influence on a paper’s content, perceptions of conflict can undermine trust in science as much as actual conflicts. Ultimately, readers should be empowered to judge whether an author’s relationships and activities are relevant to a paper’s content, necessitating transparent disclosures. An author’s full disclosure signals a commitment to transparency and bolsters trust in the scientific process.

Financial relationships – such as employment, consultancies, stock ownership, honoraria, patents, and paid expert testimony – are easily identifiable and often perceived as potential conflicts of interest, posing risks to the credibility of journals, authors, and science itself. Other interests, including personal relationships, academic competition, and intellectual beliefs, may also represent or be perceived as conflicts.

Authors should refrain from agreements with study sponsors – both for-profit and nonprofit – that impede access to all study data or hinder their ability to analyze, interpret, and publish manuscripts independently. Policies dictating where authors may publish infringe upon academic freedom principles. Authors may be required to share such agreements with the journal in confidence.

Deliberately omitting relationships or activities specified on the journal’s disclosure form constitutes misconduct. Disclosure of potential conflicts extends beyond direct support for the work. The funding statement within a manuscript should only include direct support for the described work, while individual contributions should be attributed accordingly. Distinguishing general institutional support from direct funding of the work ensures clarity.

For our research, we use an effort tracker to identify funding support for each project.

Respect for Research Participants

It is imperative that all research activities conducted within this laboratory comply with relevant laws, regulations, and institutional policies governing research ethics, safety, and integrity. This includes but is not limited to protocols for human and animal subjects research, biosafety regulations, and intellectual property rights.

When conducting research involving human subjects or animals, utmost respect must be shown for the welfare, autonomy, and rights of those involved. We will always obtain informed consent from human subjects and minimize harm to animals.

Resources:

• NIH Policies
• RCR at NU

Transparency and Openness

Open and transparent communication is essential for the advancement of science. We strive to make our methods, data, and findings accessible to the scientific community and the public whenever possible. This includes sharing research materials, publishing results in peer-reviewed journals, and presenting findings at conferences. We will also generate blog posts that are accessible to the public.

Resources

• Roles and Responsibilities
  • Defining the Role of Authors and Contributors
  • Disclosure of Financial and Nonfinancial Relationships and Activities, and Conflicts of Interest
  • Responsibilities in the Submission and Peer-Review Process
  • Protection of Research Participants
• University resources
  • RCR training program: Collaborative Institutional Training Initiative (CITI Program)
  • Northwestern Research Integrity
• The Office of Research Integrity (ORI): https://ori.hhs.gov/ (infographics below)
  • Write Ethically from Start to Finish
  • Tips for Avoiding Plagiarism
  • Tips for Presenting Scientific Images with Integrity
  • Research Trainees: What You Should Know about Research Misconduct
  • What Drives People to Commit Research Misconduct?
  • Authorship Practices to Avoid Conflicts
  • Slippery Slope to Research Misconduct