Skip to content

Workflow: Sharing Subjects Across Studies

Goal: register a new study in the same workspace that reuses subjects already defined in a previous study.

Short answer

  1. Define the subject once, in whichever study first enrolls them, using subjecthumans or subjectanimals.
  2. To link that existing subject into a different study, use the arm_2_subject compound section of study_design_edit — not subjectHumans/subjectAnimals again.
  3. Both studies must live in the same workspace — see step 2 ("Access a Workspace") in Getting Started: Workspaces and Studies: reuse your existing workspace if the new study shares subjects with a prior one.

Why it has to be done this way

A common trap

It's tempting to assume subjectHumans/subjectAnimals support referencing an existing subject, because their own field documentation says Sex/Age/Ethnicity/etc. are "conditionally required... when defining a new Subject in this row (rather than referencing an existing one)" — implying referencing is a supported path. It isn't, for this specific template.

subjectHumans and subjectAnimals both carry a hard-coded values-equal rule requiring the computed status of the Subject ID column to always be "new" — a Subject ID that already exists anywhere in the workspace will fail validation if submitted through these templates. (See Validation Rule Glossary for what values-equal and determine-combined-status actually do.)

The arm_2_subject section of study_design_edit, by contrast, is explicitly built to reference an existing subject: its Subject ID field resolves through the same foreign-key lookup used for any "must already exist" reference field, and its own documentation says directly:

"A subject may be assigned to a single arm within a study. To link a subject to more than one study's arm, create a new record for each subject to arm link."

Does anything block this at the database level?

No — and this is worth stating explicitly because arm_2_subject does carry a check-value-not-in-entity rule that looks, at first glance, like it would block exactly this. On inspection of the rule's inputs, it only compares the current row's study_accession against an in-memory, same-upload-package cache of subject→study assignments (populated by an add-values-to-entity process) — it does not block a subject already linked to a different study from a prior, separate upload. In practice it only guards against submitting the identical subject+study pair twice within one file.

Step-by-step

  1. Confirm the new study is being registered in the same workspace as the subject's original study.
  2. Register the new study (basic_study_design or SRW) and its arms/cohorts, if not already done.
  3. In study_design_edit, fill in the arm_2_subject section:
    • Subject ID — the existing subject's accession (e.g. SUB123456) or original user-defined ID.
    • Arm Or Cohort ID — the arm/cohort in the new study.
    • Age/Sex/etc. fields as required by that section (note: arm_2_subject captures its own Min Subject Age/Age Unit/Age Event per study, since a subject's age differs by study timepoint).
  4. Upload and validate as usual.