Skip to content

Patient & Caregiver Portal

Feature Status: ✅ Functional — expansion planned (see Project Plan §7 M7) Last Updated: 2026-05-06 Parent Document: Project Plan

Overview

This document specifies the Patient/Caregiver Portal — a dedicated, task-focused experience for families and study participants, separate from the site-facing EDC. The portal shares the same backend while providing a distinct UI tailored for non-clinical users.

Key principle: The portal executes consent and assessments; the EDC monitors and governs them.

Current state (2026-05-06)

The portal is implemented and functional: magic link authentication, unified task queue, eConsent signing, jsPsych assessment delivery, mobile-first UI, English/French i18n, partial-completion handling, actor attribution (caregiver vs. participant). Implementation in patient-portal/src/ and server/app/routers/portal.py.

Active expansion: REDCap-managed study scenario

For studies running in integration_mode = "redcap", the portal needs to ingest data from REDCap so participants see the same source of truth the site sees:

  • Surface REDCap-driven event/visit schedules (currently the portal reads from ScheduledVisit populated via REDCap sync — verify all fields are present and current)
  • Display REDCap-managed survey/form invitations as portal tasks (link to the survey URL or render inline where possible)
  • Reflect REDCap-side completion state back to the participant view
  • Handle REDCap as the source of truth for randomization assignments where applicable (display only — never edit)
  • Honour the REDCap fail-safe policy: if REDCap is unreachable, the portal must not invent or estimate state — show stale-data indicators rather than guess

This expansion is part of M7 (REDCap-managed study production readiness) in the project plan.

Why a Separate Portal is the Right Architecture

1. Clear separation of audiences and obligations

  • EDC UI is designed for trained staff (CRC/PI/DM/Monitor/Safety) and must expose governance, audit, queries, coding, lock, exports.
  • Portal UI is designed for patients/caregivers and must prioritize clarity, accessibility, and low burden.

Trying to make one UI serve both almost always produces:

  • Too much complexity for families
  • Too many risks of mis-clicks and misinterpretation
  • A proliferation of conditional UI states that become untestable

2. Better security posture (and easier to defend)

A portal enables:

  • Stronger isolation of PHI/clinical operations features
  • Narrower scopes for tokens and API endpoints
  • Reduced attack surface (no admin/config surfaces reachable from portal)

For inspections, it is easier to explain:

  • “Patients only see tasks assigned to them, and cannot access clinical data management features.”

3. Better patient experience and accessibility

The portal can be:

  • Mobile-first (Capacitor)
  • Plain-language
  • Lightweight
  • Resilient to interruption and partial completion
  • Built around a task queue and reminders

This directly supports pediatric caregiver workflows.

What should be shared vs separated

You should share:

  • Participant registry (with portal identities mapped to participants)
  • Study schedule (StudyEvent instances)
  • Assessment engine (jsPsych delivery + result capture)
  • Consent service (templates, versions, signature capture)
  • Notification service (email/SMS/push)
  • Audit event store (single source of truth)
  • Metadata versions (so portal behavior is versioned)
  • EDC Web App (staff)
  • Portal Web/Mobile App (patient/caregiver)

Even with one backend, expose two API gateways or at least two routing scopes:

  • /api/edc/* (staff)
  • /api/portal/* (patients/caregivers)

This allows:

  • Different authentication policies
  • Narrower scopes
  • Easier monitoring and rate limiting

Key design implications for your existing EDC architecture

For rare pediatric trials, the portal should own:

  • Re-consent prompts
  • Consent signature flows
  • Assent transitions (age-based)
  • Consent status feedback

The EDC can still view consent status, but the portal executes it.

2. Assessments should run entirely within the portal

Your current flow already aligns:

  • Battery assigned from backend
  • Completed on web/mobile
  • Submitted to backend

Portal should handle:

  • Task list
  • Launch assessment
  • Pause/resume
  • Partial completion reasons
  • Device/tech troubleshooting

EDC should handle:

  • Compliance dashboards
  • Resend/remind (optional; or portal notifications can be automated)
  • Adjudication flags (DM)

3. Portal should not expose clinical “data entry”

Portal is not “forms.” It is “tasks.”

Portal shouldn’t display CRFs or site-entered data.

It can display:

  • “Visit upcoming” reminders
  • “Questionnaire due”
  • “Consent update required”
  • Contact info

Avoid:

  • “Labs, AE listings, queries” unless you have a specific patient-facing workflow and IRB-approved language.

Identity and role model (critical)

Portal introduces new actors:

  • Caregiver Primary
  • Caregiver Delegate
  • Participant (child/adolescent)

These are not EDC roles; they are subject-linked identities.

Recommendations:

  • Use a ParticipantAccount entity with:
  • links to ParticipantID
  • identity provider subject
  • permitted actions (consent, assessment, diaries)
  • delegation rules
  • Require explicit attribution:
  • “completed by caregiver” vs “completed by participant”
  • stored on each assessment instance and consent signature event

This is essential for pediatric validity and audits.

Audit trail and compliance with a portal

A portal strengthens audit defensibility if you do this:

  • All portal actions log audit events with:
  • actor_type = HUMAN
  • actor_role = CAREGIVER or PARTICIPANT
  • participant_id bound
  • metadata_version_id bound
  • consent_version_id / battery_version_id bound

Add two portal-specific event families:

  • PORTAL_AUTH_* (login, MFA, device)
  • PORTAL_TASK_* (task assigned, opened, completed, abandoned)

Inspectors will like the clarity.

Suggested UI IA for the portal

Keep it minimal and task-centric.

Portal Sidebar / Tabs

  • Home
  • Tasks
  • Assessments
  • Consent
  • Messages / Contact
  • Settings

Home

  • “What’s next”
  • Consent status banner
  • Next visit reminder
  • Support contact

Tasks

  • List of due/overdue tasks (consent, assessments)
  • Estimated time
  • “Pause/resume” state

Assessments

  • History and status (submitted/partial)
  • Launch assessment
  • Troubleshooting
  • Active consent version
  • Re-consent flow
  • Download/view consent

Messages / Contact

  • Study contact details
  • FAQ
  • Optional secure messaging (if you implement it)

Implementation plan (high-level)

Phase 1: Backend readiness (no UI change yet)

  • Introduce portal actor model (Caregiver/Participant identity mapping)
  • Split API scopes (/portal/* endpoints)
  • Add portal audit events
  • Task assignment service (consent + assessments)

Phase 2: Portal MVP

  • Authentication + participant binding
  • Task list
  • Launch jsPsych assessments
  • Consent signing flow
  • Notifications (basic)

Phase 3: Rare pediatric enhancements

  • Delegated caregiver access
  • Age-based transitions (assent → consent)
  • Partial completion capture and reasons
  • Burden minimization features

Phase 4: Inspection hardening

  • Audit reports specific to portal actions
  • SOC2-style controls if needed
  • Enhanced device logging and troubleshooting

Risks and mitigations

Risk: Duplication of logic between EDC and portal

Mitigation:

  • Treat backend services as authoritative (tasks, gating, versions)
  • Frontends are thin clients

Risk: Confusing portal users with clinical terminology

Mitigation:

  • Task language library + study-specific phrasing
  • Never show “queries,” “CRFs,” “coding,” “metadata”

Risk: Consent/assessments drift from metadata versions

Mitigation:

  • Portal always requests tasks from backend, never caches definitions
  • Every task is version-stamped at creation

Recommendation

Proceed with a separate Patient/Caregiver Portal sharing the same backend, with:

  1. Separate UI surface and authentication policy
  2. Separate API namespace and token scopes
  3. Shared governance (metadata versions, audit trail, task assignment)
  4. Portal as the “execution layer” for eConsent and assessments

This is the cleanest and most defensible solution for rare pediatric trials.

If you want, I can produce:

  • A portal-specific wireframe description (pages + components) aligned to this split
  • A backend service contract (API endpoints + scopes)
  • A portal audit event taxonomy extension (caregiver/participant-specific)