Skip to content

Participant registry

This is an excellent question, because ** patient registries—especially rare disease registries—are not adjacent to an EDC; they are structurally upstream and downstream of it . If you design this correctly, your EDC suite becomes a **continuous learning system rather than a collection of study tools.

Below is a ** clear, regulator-aware way to include a rare disease patient registry as a first-class component of your EDC platform , without compromising trial integrity or blurring consent boundaries.**

1. Reframe the relationship: Registry ≠ Study

Core principle (non-negotiable)

A registry is not a study, and a study is not a registry — but they can share infrastructure, standards, and participants.

Regulators are very sensitive to this distinction.

Your platform should treat registries and trials as:

  • Separate governance entities
  • Separate consent regimes
  • Separate data lifecycles
  • Optionally linked at the participant level

This framing unlocks power without regulatory risk.

2. Where the registry fits in the platform architecture

Add a new top-level capability to the suite

Conceptually, your platform becomes:

Platform Suite
├── Clinical Trials (EDC)
├── Patient Registries
├── Digital Assessments
├── Consent & Identity
├── AI Services
└── Analytics & Exports

The registry is a peer to the EDC, not a feature inside it.

3. Registry types you should explicitly support

Your design should accommodate at least four registry archetypes:

3.1 Observational / Natural History Registry

  • Longitudinal data collection
  • No intervention
  • Often multi-site, international
  • Long duration (years to decades)

3.2 Trial-Adjacent Registry

  • Pre-trial identification
  • Run-in data
  • Post-trial follow-up
  • Real-world evidence extension

3.3 Platform Registry (Disease-Wide)

  • Multiple studies reference the same registry
  • Shared phenotype model
  • Multiple sponsors over time

3.4 Patient-Initiated Registry

  • Direct patient/caregiver enrollment
  • Portal-first data collection
  • Later site confirmation or validation

Your platform can support all four if you design the registry layer correctly.

4. Core registry capabilities (what must exist)

4.1 Registry governance (parallel to EDC governance)

Registries require:

  • Registry definition (scope, disease, objectives)
  • Versioned data model (phenotype definitions evolve)
  • Registry-specific SOPs
  • Registry-specific consent(s)
  • Access rules (who can see what)

This should mirror—but not reuse—your Metadata Versions model.

Think: RegistryMetadataVersion parallel to StudyMetadataVersion.

4.2 Registry data model (rare disease-optimized)

Unlike CRF-centric EDC data, registry data should be:

  • Phenotype-centric, not visit-centric
  • Stateful, not episodic
  • Sparse and heterogeneous
  • Longitudinal across life stages

Key registry objects:

  • Disease diagnosis (with uncertainty flags)
  • Genotype / variant data (where permitted)
  • Onset milestones
  • Functional states (motor, cognitive, respiratory)
  • Treatments and exposures
  • Outcomes and events
  • Patient-reported and caregiver-reported data

Your ODM alignment still matters, but ** registry ODM usage is looser and more extensible .**

4.3 Registry portal (shared with trial portal)

Your Patient/Caregiver Portal becomes the natural front door for registries.

Portal capabilities:

  • Registry enrollment
  • Registry-specific consent
  • Ongoing questionnaires and assessments
  • Data review and correction (where permitted)
  • Re-contact permissions

Trials can later “attach” to registry participants only with explicit consent .

5. Linking registries and trials safely (the hard part)

5.1 Identity linking (participant continuity)

Introduce a Participant Master Identity layer:

  • One person → multiple roles:
  • Registry participant
  • Trial participant (Study A, Study B)
  • Each context has:
  • Separate consent
  • Separate permissions
  • Separate audit trails

This enables:

  • Trial feasibility
  • Longitudinal follow-up
  • Cross-study continuity

Without ever “leaking” data across contexts.

Registry consent must explicitly control:

  • Use for feasibility
  • Use for trial recruitment
  • Use for external data sharing
  • Use for AI/analytics

Trial consent must explicitly state:

  • Whether registry data may be imported
  • Whether trial data flows back to registry

No implicit reuse. Ever.

Your consent engine already supports this—this is a configuration and policy exercise.

6. Registry → Trial workflows (high-value use cases)

6.1 Feasibility and cohort discovery

  • AI-assisted phenotype matching
  • Counts only (unless consent allows contact)
  • Site-specific filtering

6.2 Pre-population of trial data

With consent:

  • Demographics
  • Baseline phenotype
  • Prior assessments

Marked clearly as:

  • “Imported from registry”
  • Source-attributed
  • Locked or editable per protocol

6.3 Post-trial follow-up

  • Trial concludes
  • Participant continues in registry
  • Outcomes captured longitudinally

This is gold for rare disease sponsors and regulators.

7. AI’s role in registry support (where it shines)

AI is particularly powerful in registries because:

  • Data are messy
  • Longitudinal patterns matter
  • Small N amplifies signal and noise

Appropriate AI uses

  • Phenotype normalization
  • Longitudinal state summarization
  • Missingness pattern detection
  • Trial eligibility pre-screening (never auto-enrollment)
  • Natural history trajectory modeling

Guardrails (important)

  • AI never assigns diagnosis
  • AI never enrolls participants
  • AI outputs are advisory, not determinative
  • All AI outputs are auditable

This mirrors your EDC AI philosophy.

8. Exports and regulatory posture

Registries serve different regulatory audiences:

  • Regulators (natural history)
  • HTA bodies
  • Sponsors
  • Patient organizations

Your platform should support:

  • Registry-specific exports (CSV, OMOP-like)
  • Trial-linked exports with provenance
  • Clear separation of observational vs interventional data

Health Canada, FDA, and EMA are increasingly receptive to registry-supported evidence when governance is clear.

9. Organizational advantage of including registries

If you include registries in the same suite:

  • You shorten trial startup timelines
  • You improve feasibility accuracy
  • You reduce participant burden
  • You strengthen rare disease networks
  • You create defensible real-world evidence pipelines

Most EDCs cannot do this cleanly.

Phase 1 – Registry foundation

  • Registry entity model
  • Registry consent
  • Portal enrollment
  • Longitudinal phenotype capture

Phase 2 – Registry ↔ Trial linkage

  • Participant master identity
  • Consent-gated linking
  • Feasibility queries

Phase 3 – Advanced analytics

  • AI phenotype summarization
  • Natural history modeling
  • Post-trial follow-up integration

Bottom line

The correct mental model is:

Your EDC is one execution surface of a broader clinical research platform that also supports registries, natural history, and learning health systems.

If you build the registry as a first-class peer—not an add-on—you create a platform uniquely suited for rare disease research while remaining fully generalizable.

If you want next steps

I can:

  • Design a Registry Architecture & Governance spec
  • Define a Registry Metadata Model (rare disease–optimized)
  • Create Registry–Trial Consent Matrices
  • Draft Health Canada–friendly registry positioning language
  • Design Registry UI wireframes (portal + admin)

Just tell me which artifact you want next.