Rare Disease & Pediatric Integration¶

Feature Status: ✅ All Phases Complete Last Updated: 2026-01-21 Parent Document: Project Plan

Implementation Status¶

Phase	Status	Description
Phase 1	✅ Complete	Foundation - Feature flag, enhanced caregiver model, actor badges
Phase 2	✅ Complete	Assessment burden minimization, partial completions
Phase 3	✅ Complete	Phenotype tracking, amendment narratives
Phase 4	✅ Complete	Exports, narratives, inspection hardening

Phase 4 Implementation Details (Just Completed)¶

Backend: - Migration 024_rare_disease_audit.py - Extended audit event types for portal actions - NarrativeExportService - Participant-level longitudinal summaries for regulatory packages - Extended SDTM export with phenotype mappings (FA domain), actor attribution - New export endpoints: narrative summary, phenotype export, actor attribution report, version crossover report - Portal /summary endpoint for patient-facing "What We Have So Far" data

Researcher Portal: - ParticipantAuditViewer component - Participant-centric audit viewer for inspection support - Extended Export page with "Rare Disease" tab containing all Phase 4 export types - Category filters for audit events (consent, assessment, phenotype, actor, amendment, visit, data)

Patient Portal: - Summary page - Plain-language "What We Have So Far" participant journey summary - Progress visualization with completion ring - Journey milestones timeline - Actor attribution summary (who completed tasks - caregiver vs participant) - Link from Home page for rare pediatric mode participants

Phase 3 Implementation Details¶

Backend: - Migration 023_phenotype_tracking.py - phenotype_state_transitions and amendment_participant_impacts tables - PhenotypeStateTransition and AmendmentParticipantImpact models - phenotype_service.py - CRUD, state transitions, timeline queries, summary generation - amendment_impact_service.py - Impact preview, apply amendments, narrative generation - REST API endpoints in phenotypes.py and amendments.py routers

Researcher Portal: - PhenotypeTimeline component - Visual timeline with filtering by category and significance - PhenotypeCard component - Individual phenotype display with state info - ParticipantDetail page - New tabbed interface with Phenotype Timeline tab

Patient Portal: - AmendmentBanner component - Non-alarmist study update notifications with guided re-consent flow

Overview¶

This document specifies adaptations required to make the Metricis EDC platform truly fit-for-purpose for rare disease clinical trials in children. These requirements are about changing the system's default assumptions, not just adding features.

Rare pediatric trials stress every weak point in conventional EDCs: small N, heterogeneous phenotypes, long timelines, protocol fluidity, caregiver-mediated data, and ethical oversight.

Related specifications: - Patient/Caregiver Portal - UI for families - AI Agent Facilitation - Burden reduction through AI assistance

1. Change the Unit of Truth: Phenotype Over Visit¶

Why this matters¶

Rare pediatric diseases rarely progress neatly by visit. Clinicians and regulators care about state transitions (loss of ambulation, new seizure type, feeding tube placement), not just scheduled timepoints.

Platform advice¶

Treat stateful clinical attributes as first-class objects:
Motor function state
Seizure burden/type
Vision/hearing milestones
Respiratory support status
Cognitive/behavioral regression
Allow these to:
Persist longitudinally
Change asynchronously (not tied to visits)
Trigger queries, assessments, or safety workflows

Concrete implication

Your ODM mapping should emphasize:
Repeating ItemGroups with temporal semantics
Explicit “state change” events
Your UI should surface:
“What changed since last review?” summaries
State timelines on the participant profile

This aligns extremely well with your jsPsych batteries and AI extraction ambitions.

2. Make protocol amendments the norm, not the exception¶

Why this matters¶

In rare pediatric trials:

Natural history evolves mid-study
Endpoints are refined
New biomarkers emerge
Age-related instruments change

If amendments feel “heavy,” sites disengage.

Platform advice¶

You already did the hard part. Now lean into it:

Promote Amendment Operations to a visible, routine workflow:
Amendment dashboards
Impact previews by participant
Re-consent + assessment changes treated as expected events
Provide ** participant-level amendment narratives :**
“This child was assessed under v1 until age 6; v2 thereafter”

Key differentiator

Your Amendment SOP + metadata versioning is not overhead—it is a competitive advantage in rare disease trials.

3. Treat caregivers as first-class actors (without breaking GCP)¶

Why this matters¶

In pediatrics:

The participant often cannot self-report
Caregivers complete PROs, eConsent, and assessments
Responsibility shifts over time (e.g., adolescent assent)

Platform advice¶

Introduce a ** Caregiver Actor Model :**
Caregiver identity linked to participant
Role scoped to specific actions (eConsent, assessments, diaries)
Support ** dynamic consent authority :**
Parent-only → shared assent → participant-only
Audit trail must clearly distinguish:
CRC vs caregiver vs participant actions

Concrete UI implication

Assessments and eConsent screens must clearly display:
“Completed by: Parent / Legal Guardian”
This is inspection-critical in pediatric trials.

4. Embrace sparse data and non-statistical endpoints¶

Why this matters¶

Rare pediatric trials often rely on:

Single-arm designs
External controls
Clinically meaningful change rather than p-values

Platform advice¶

Avoid hard assumptions that:
Every visit must have every form
Missing data = error
Encode protocol-allowed missingness explicitly:
“Not applicable due to disease progression”
“Assessment impossible due to regression”

EDC-specific implication

Missingness reasons must be:
Structured
Auditable
Exportable
Your query engine should distinguish:
“Missing and expected”
“Missing and problematic”

This is especially important for regulators reviewing rare disease data.

5. Design assessments for burden minimization, not completeness¶

Why this matters¶

Children with rare disease:

Fatigue easily
Regress cognitively
Cannot tolerate long batteries

Platform advice (jsPsych strength)¶

Support ** adaptive batteries :**
Shortened versions
Early termination with valid partial scores
Capture ** assessment feasibility metadata :**
“Child unable to complete due to fatigue”
Treat partial completion as analyzable, not failure

Key differentiator

Most EDCs treat partial assessments as “bad data.”

Rare pediatric trials need them treated as clinically meaningful signals.

6. Build age- and development-aware logic everywhere¶

Why this matters¶

A 2-year-old and a 12-year-old with the same diagnosis are not comparable.

Platform advice¶

Make age at assessment a first-class derived variable
Allow:
Automatic instrument switching by age band
Conditional item visibility based on developmental stage
Ensure:
Age transitions trigger re-consent / assent logic
Assessments adapt automatically

Your existing Rules & Derivations and Metadata Versions are ideal for this—use them aggressively.

7. Optimize for longitudinal continuity, not site throughput¶

Why this matters¶

Rare pediatric trials are:

Long (years)
Site-staff turnover is common
Families often relocate

Platform advice¶

Emphasize ** participant narrative continuity :**
Timeline views
Clinician summaries auto-generated by AI
Allow site transitions without data fragmentation
Ensure that monitors can understand a child’s entire journey quickly

This directly supports Health Canada and FDA expectations for rare disease review.

8. Use AI as a ****¶

burden reducer¶

, not a decision-maker¶

Why this matters¶

In pediatric rare disease, trust is fragile.

Platform advice¶

Your AI strategy is correct—now tune it for pediatrics:

AI should:
Draft visit schedules from protocols
Propose assessment plans
Summarize longitudinal change
Flag inconsistencies
AI must never:
Decide eligibility
Override consent
Interpret safety events autonomously

Crucial

Always show why the AI suggested something, and link it to protocol text or prior data.

9. Exports must tell a story, not just satisfy CDISC¶

Why this matters¶

Regulators reviewing rare pediatric trials want to understand:

Disease course
Meaningful change
Individual trajectories

Platform advice¶

Supplement standard SDTM/ADaM with:
Narrative-friendly exports
Participant-level longitudinal summaries
Ensure every export retains:
Metadata version
Consent version
Assessment version
Age at time of assessment

This makes your platform particularly attractive to sponsors in rare disease.

10. Make ethics and transparency visible in the UI¶

Why this matters¶

Pediatric rare disease trials are ethically sensitive.

Platform advice¶

Surface:
Consent status prominently
Re-consent triggers clearly
Data use boundaries
Provide audit trail views that are:
Human-readable
Participant-centric

This builds confidence with REBs, parents, and regulators.

Below is a design specification for participant and caregiver UI adaptations tailored to rare disease clinical trials in children, explicitly aligned with your EDC architecture (eConsent, jsPsych assessments, amendment workflows, audit rigor, AI assistance). This is written as a wireframe-level functional spec that a product/design team can implement directly.

Participant & Caregiver UI Adaptations¶

Rare Pediatric Disease Trials

1. Design Principles (Non-Negotiable)¶

Clarity over completeness Participants and caregivers should never see “the study”—only what matters now .
Caregiver-first, child-aware The system must assume caregiver mediation by default, with controlled transition to child/adolescent participation.
Low burden, high trust Every interaction should answer:
Why am I being asked this?
How long will this take?
What happens if we can’t complete it?
Ethics and consent are always visible Consent status is not buried; it is a persistent, reassuring signal.
Graceful failure is expected Fatigue, regression, hospitalization, device failure are normal—not errors.

2. Actor Model (UI-Visible)¶

The UI must make who is acting explicit at all times.

Actors¶

Caregiver (Primary)
Caregiver (Secondary / Delegate)
Participant (Child / Adolescent)
Participant (Assent-only)

Persistent UI Element¶

Actor Badge (Top Right)

“Acting as: Parent / Legal Guardian”
Switch actor (if permitted)
Tooltip: explains responsibility and audit attribution

This is inspection-critical.

3. Participant/Caregiver Home Dashboard¶

Purpose¶

A single, calm landing page answering:

“What do I need to do next?”

Components¶

A. Today’s Actions (Primary)¶

Card list, ordered by urgency:

“Consent update required”
“Assessment due”
“Upcoming visit reminder”
“Nothing required today”

Each card shows:

Purpose (plain language)
Estimated time
Deadline/window
Who completes it (child / caregiver)

B. Study Timeline (Simplified)¶

Visual timeline (past → now → next)
No protocol jargon
Labels like:
“Baseline visit”
“Monthly check-in”
“Questionnaire”

Current consent version
Signed date
If re-consent is pending: prominent banner
“View consent” (read-only)

D. Support & Contact¶

“Need help?” button
Study contact info
Emergency instructions (if applicable)

4. eConsent UI (Pediatric-Optimized)¶

Key Adaptations¶

Plain-language summary
Why the study changed
What’s new
What stays the same
Full consent document
Printable/downloadable version

B. Signature Flow¶

Explicit signer identity:
Parent / Guardian
Participant (assent)
Clear progression:
Review → Acknowledge → Sign
Confirmation screen with:
Date/time
Version
Who signed

C. Age-Triggered Transitions¶

When participant reaches age threshold:

UI explains:
“Your child is now old enough to provide assent/consent”
Guided transition flow
No silent changes

5. Assessments UI (jsPsych / eCOA)¶

A. Assessment Landing Page¶

Before starting:

Purpose (“This helps us understand how your child is doing”)
Estimated duration
Who should complete it
Ability to postpone
“What if we can’t finish?” explanation

B. During Assessment¶

Progress indicator (not percentage, but steps)
“Pause and return later” always available
Fatigue-safe UI:
Large touch targets
Minimal cognitive load
Visible “Exit safely” option

C. Partial Completion Handling¶

On exit:

Gentle prompt:
“Would you like to tell us why you stopped?”
Structured options:
Too tired
Became distressed
Technical issue
Other (optional text)

System behavior

Partial data saved
Marked as valid but incomplete
No error language shown to user

6. Caregiver-Completed vs Child-Completed Distinction¶

UI Requirement¶

Every assessment and form must clearly show:

“Completed by: Parent / Caregiver”
or “Completed by: Child”

Why this matters¶

Critical for pediatric validity
Required for audit and interpretation
Prevents ambiguity during inspection

7. Visit & Data Transparency (Without Overwhelm)¶

Participant View¶

No CRF language
No field-level data
High-level status only:
“Visit completed”
“Assessment submitted”
“Clinic visit scheduled”

Optional “What we have so far” Summary¶

Plain-language summary, AI-generated but human-approved:

“Since last visit, we recorded…”
No clinical interpretation
No scores unless protocol allows

When an Amendment Occurs¶

“The study has been updated”
Clear explanation of impact:
“This does not change your child’s treatment”
or “This adds a new questionnaire”

Guided Flow¶

Explanation
Re-consent
Confirmation
Return to dashboard

No other tasks unlocked until re-consent is complete (but explained gently).

9. Notifications & Reminders (Rare Disease-Sensitive)¶

Principles¶

Fewer, clearer notifications
Configurable channels (email, SMS, app)
Respect caregiver overload

Notification Content¶

One request per message
Clear deadline
Direct deep link
Reassuring tone

Example:

“You have a short questionnaire due this week.

It takes about 5 minutes. You can pause anytime.”

10. Accessibility & Inclusion (Critical)¶

Mandatory¶

WCAG 2.1 AA compliance
Large text mode
High-contrast mode
Screen-reader compatibility

Pediatric-specific¶

Simple language toggle
Icon-supported navigation
Minimal scrolling

11. Audit & Transparency (Invisible but Real)¶

While hidden from participants, the system must:

Attribute every action to:
Caregiver vs child
Record:
Consent versions
Assessment versions
Partial completions and reasons

This ensures ** participant trust without exposing system complexity .**

12. “Rare Pediatric Mode” Feature Flag (Recommended)¶

Enable a study-level configuration that:

Defaults to caregiver-mediated flows
Enables partial assessments
Enables age-based logic
Softens language
Adjusts notification cadence

This avoids bespoke builds per study.

Summary¶

These UI adaptations ensure that your EDC:

Respects the realities of rare pediatric disease
Protects children and caregivers ethically
Reduces burden without compromising data integrity
Stands up to Health Canada and global regulatory scrutiny
Differentiates your platform meaningfully from generic EDCs

If you want next steps¶

I can:

Convert this into Figma-ready wireframe annotations
Produce participant-facing language guidelines
Define caregiver role RBAC extensions
Map UI elements to audit events and backend services

Just tell me what you’d like next.

Bottom line¶

To tailor your EDC for rare pediatric disease trials:

Design for heterogeneity, longitudinal change, caregiver mediation, and ethical oversight—then let AI reduce burden without ever removing accountability.

Your current architecture (metadata versioning, jsPsych integration, AI-assisted setup, audit rigor) is exceptionally well suited to rare pediatric trials if you lean into these principles.

If you want next steps, I can:

Propose a “Rare Pediatric Trial Mode” configuration profile
Define minimum viable pediatric compliance checks
Map these principles to Health Canada rare disease guidance
Design participant/caregiver UI adaptations

Just tell me which direction you want to go.

Below is a production-grade AI agent prompt specifically designed to read a file called rare-disease-integration.md and produce a concrete, regulated-ready implementation plan for integrating rare disease (particularly pediatric) requirements into your EDC platform.

This prompt is aligned with:

The EDC architecture you have defined
Your governance, amendment, audit, and AI-assistant model
Health Canada / ICH-GCP expectations
Rare pediatric trial realities

You can use this prompt verbatim with a reasoning-capable agent.

# System Prompt: Rare Disease EDC Integration Architect

## Role

You are a senior clinical systems architect specializing in:
- Rare disease clinical trials
- Pediatric research ethics and governance
- Regulated Electronic Data Capture (EDC) systems
- Longitudinal phenotype modeling
- Caregiver-mediated data collection
- CDISC ODM / SDTM alignment
- Health Canada and ICH-GCP compliance

You are responsible for translating rare-disease design guidance into an **actionable implementation plan** for a production EDC platform.

---

## Inputs

You are provided with the following authoritative document:

- `rare-disease-integration.md`  
  This document defines design principles, constraints, and expectations for supporting rare disease clinical trials, particularly in children.

Assume this document builds upon an existing EDC architecture that includes:
- Versioned metadata governance
- AI-assisted study setup
- jsPsych-based assessments
- eConsent
- Protocol amendment workflows
- Inspection-grade audit trails

Treat `rare-disease-integration.md` as **normative product guidance**, not optional commentary.

---

## Objective

Produce a **detailed implementation plan** that answers:

> “What concrete system changes, features, and safeguards are required to make this EDC truly fit-for-purpose for rare pediatric disease trials?”

Your plan must bridge:
- UX and workflow changes
- Backend data models
- Governance and audit
- AI-agent facilitation
- Regulatory defensibility

---

## Required Outputs

You MUST produce the following sections, in order.

---

### 1. Rare Disease Design Requirements (Operationalized)

Translate the principles in `rare-disease-integration.md` into a **clear list of system requirements**, grouped by:
- Data model
- UI/UX
- Workflow
- Governance
- Export/reporting

Avoid restating principles—focus on **what must be built or changed**.

---

### 2. Domain Model Extensions

Define the **new or extended domain objects** required to support rare disease and pediatric trials.

For each object:
- Name
- Purpose
- Key attributes
- Lifecycle and versioning
- Relationship to existing EDC objects

You MUST explicitly address:
- Longitudinal phenotype/state objects
- Caregiver actors
- Developmental stage / age-aware logic
- Assessment feasibility and partial completion metadata

---

### 3. Study Setup & Amendment Workflow Changes

Describe how rare disease assumptions change:

- Study initiation workflows
- Protocol amendment handling
- Re-consent and assent transitions
- Assessment replacement or evolution over time

Explicitly map these changes to:
- Metadata versions
- Amendment SOP steps
- Audit trail requirements

---

### 4. Assessments & Burden Minimization Strategy

Define how the system should support:
- Adaptive or shortened assessments
- Partial completions as valid data
- Caregiver-completed instruments
- Age- and development-aware assessment switching

Include:
- UI behavior
- Validation logic
- Export implications

---

### 5. AI Agent Responsibilities and Guardrails (Rare Disease Mode)

Specify how AI agents should be used to:
- Reduce setup and operational burden
- Summarize longitudinal change
- Flag clinically meaningful transitions

And explicitly state:
- What AI must NEVER do
- Required human approvals
- Required audit events

---

### 6. Role-Based Visibility and Responsibility Adjustments

Describe any changes needed to:
- CRC
- PI
- Data Manager
- Monitor
- Caregiver roles

to safely support pediatric rare disease trials.

---

### 7. Export, Analysis, and Regulator Review Considerations

Describe how exports must change to support:
- Small-N interpretation
- Longitudinal narratives
- External controls or natural history comparisons

Include:
- Metadata required in exports
- Recommended supplemental exports beyond SDTM/ADaM

---

### 8. Phased Implementation Plan

Propose a **realistic delivery plan**, for example:

- Phase 1: Data model and caregiver support
- Phase 2: Assessment adaptations
- Phase 3: AI summarization and burden reduction
- Phase 4: Inspection hardening

For each phase:
- Scope
- Risks
- Exit criteria

---

### 9. Failure Modes Unique to Rare Pediatric Trials

Identify:
- Top 5–10 failure modes specific to rare pediatric trials
- How the proposed design prevents or mitigates each

---

## Constraints and Expectations

- Be concrete and implementation-oriented
- Do not hand-wave with “support” or “ensure”
- Assume regulatory inspection
- Assume long study duration and evolving protocols
- Prefer explicit governance over automation

---

## Output Quality Bar

The final output should be suitable to become:
- An internal architecture and delivery plan
- A backlog seed for multiple teams
- A design review artifact for clinical leadership

Begin only after fully reading and reasoning over `rare-disease-integration.md`.

Optional follow-ons¶

If you want, I can also generate:

A companion prompt for a data-modeling agent
A UI wireframe prompt specifically for caregiver/participant views
A Health Canada–focused rare disease compliance checklist
A “Rare Pediatric Trial Mode” configuration spec

Just tell me what you’d like next.

Rare Disease & Pediatric Integration¶

Implementation Status¶

Phase 4 Implementation Details (Just Completed)¶

Phase 3 Implementation Details¶

Overview¶

1. Change the Unit of Truth: Phenotype Over Visit¶

Why this matters¶

Platform advice¶

2. Make protocol amendments the norm, not the exception¶

Why this matters¶

Platform advice¶

3. Treat caregivers as first-class actors (without breaking GCP)¶

Why this matters¶

Platform advice¶

4. Embrace sparse data and non-statistical endpoints¶

Why this matters¶

Platform advice¶

5. Design assessments for burden minimization, not completeness¶

Why this matters¶

Platform advice (jsPsych strength)¶

6. Build age- and development-aware logic everywhere¶

Why this matters¶

Platform advice¶

7. Optimize for longitudinal continuity, not site throughput¶

Why this matters¶

Platform advice¶

8. Use AI as a ****¶

burden reducer¶

, not a decision-maker¶

Why this matters¶

Platform advice¶

9. Exports must tell a story, not just satisfy CDISC¶

Why this matters¶

Platform advice¶

10. Make ethics and transparency visible in the UI¶

Why this matters¶

Platform advice¶

Participant & Caregiver UI Adaptations¶

1. Design Principles (Non-Negotiable)¶

2. Actor Model (UI-Visible)¶

Actors¶

Persistent UI Element¶

3. Participant/Caregiver Home Dashboard¶

Purpose¶

Components¶

A. Today’s Actions (Primary)¶

B. Study Timeline (Simplified)¶

C. Consent Status Panel (Always Visible)¶

D. Support & Contact¶

4. eConsent UI (Pediatric-Optimized)¶

Key Adaptations¶

A. Layered Consent Presentation¶

B. Signature Flow¶

C. Age-Triggered Transitions¶

5. Assessments UI (jsPsych / eCOA)¶

A. Assessment Landing Page¶

B. During Assessment¶

C. Partial Completion Handling¶

6. Caregiver-Completed vs Child-Completed Distinction¶

UI Requirement¶

Why this matters¶

7. Visit & Data Transparency (Without Overwhelm)¶

Participant View¶

Optional “What we have so far” Summary¶

8. Amendment & Re-Consent Experience¶

When an Amendment Occurs¶

Banner (Non-Alarmist)¶

Guided Flow¶

9. Notifications & Reminders (Rare Disease-Sensitive)¶

Principles¶

Notification Content¶

10. Accessibility & Inclusion (Critical)¶

Mandatory¶

Pediatric-specific¶

11. Audit & Transparency (Invisible but Real)¶

12. “Rare Pediatric Mode” Feature Flag (Recommended)¶

Summary¶

If you want next steps¶

Bottom line¶

Optional follow-ons¶