Participant Pools & Cross‑Project Harmonization Platform

A unified intake and harmonization layer that keeps participant data consistent across labs and projects.

Participant pools and cross‑project harmonization

Single

Point of Entry

Stable

GUIDs

De‑ID

Exports

Auto

Data Sync

Repeat

Sessions

Overview

                The Challenge: Multi‑lab workflows often create fragmented intake records, inconsistent identifiers, and ad‑hoc data sharing.
                
                The Solution: A unified intake and harmonization layer that standardizes records, assigns stable GUIDs, and supports IRB‑safe coordination through de‑identified exports and controlled system‑to‑system sync.

Python

REDCap API

CSV Source‑of‑Truth

GUID Matching

De‑ID Export

Autopush

System Architecture

Single Point of Entry

Participants enter through one consistent intake path that serves all projects.

↓

Identity Resolution + Stable GUID

Deterministic matching reduces duplicates and maintains a stable, cross‑project ID.

↓

Harmonized System Sync

Structured updates flow to downstream systems with repeat‑safe appends.

↓

IRB‑Safe De‑ID Export

De‑identified outputs enable coordination without exposing PHI.

Screenshots

                Participant Check‑In Kiosk Deployment: A streamlined, front‑of‑house intake experience that captures consent, resolves identity, and synchronizes visits to REDCap in real time.
            

Unified check-in flow with consent and participant intake.

Guardian newsletter contact modal and preference selection.

Core Modules

🧭

Unified Intake

Single intake flow for participants and guardians. Captures core demographics, consent, and session context in a consistent schema.

# Intake normalized into canonical fields
payload = {
  "name": "Participant",
  "dob": "YYYY-MM-DD",
  "consent": "Yes/No",
  "session_code": "PROJECT"
}

Kiosk UI

Normalization

🧩

GUID Matching Engine

Deterministic matching with identity confirmation to avoid duplicates and preserve stable IDs.

# Match + confirm identity
if match_score >= 2:
    guid = existing_guid
else:
    guid = new_guid()

GUID

Deduping

Scoring

🔁

Repeat Visit Capture

Every check‑in appends a new session instance with timestamped metadata.

# Session instance stored as repeatable entry
entry = {
  "instance": next_instance,
  "timestamp": now_iso,
  "session_code": project_code
}

Repeating Instruments

Visit Log

📬

Newsletter Preferences

Handles guardian‑specific contact preferences and delivery routing (participant only, guardian only, or both).

# Preference routing with safe defaults
contact = guardian_contact or participant_contact
route = selected_pref or "participant_only"

Consent

Preferences

🔌

REDCap Autopush

Each completed check‑in pushes a harmonized record update, appending repeatable entries safely.

# Lookup by GUID and append repeat instances
record_id = resolve_record_id(guid)
next_instance = current_max + 1
import_records(sync_payload)

REDCap API

Scripted Push

🕶️

De‑Identified Exports

Parallel de‑identified exports allow safe cross‑project reporting without exposing PHI.

# De‑ID export includes session metadata only
fields = ["guid", "session", "timestamp"]
write_deidentified_csv(fields)

IRB‑Safe

Cross‑Project

API Integrations

REDCap API — Record lookup by GUID, repeat‑safe imports, and harmonized updates
Local CSV Source‑of‑Truth — Canonical storage for matching, sessions, and contact history

🔐 Security Notice: Credentials remain local and are never embedded in the UI. All system syncs are executed via saved scripts in the repository.

Impact Metrics

⏱️

Fewer Duplicates

Stable GUIDs and identity resolution reduce duplicate records across labs and projects.

🧭

Single Entry Point

One consistent intake experience creates harmonized fields for all downstream projects.

🧪

IRB‑Safe Sharing

De‑identified exports enable coordination without exposing PHI to collaborators.

✅

Repeat‑Ready

Repeatable session tracking preserves longitudinal history without manual overhead.

Technical Workflow

                Event‑Driven Intake:
                Step 1 — Participant completes intake
Step 2 — GUID match + session creation
Step 3 — Harmonized system sync
Step 4 — De‑identified export updates

            

# Sync enabled via environment configuration
export INTAKE_SYNC_ENABLED=1
export SYNC_API_URL="https://.../api/"
export SYNC_TOKEN_PATH="/path/to/key.txt"

Demos

Participant pools and harmonization (visual preview)